By showing you understand the constraints the developers were under, and acknowledging their frame of mind. Criticism is fine, giving it without understanding the context is not.
If you are able to summarize the problem in such a way that the developers say 'That is right', and they are not correcting you further on your understanding of the problem, then any criticism from your side is not as much of an attack. By framing it like 'I might be missing some context here, I think X, Y, and Z were your reasons for choosing this approach, but I think there is a factor F you haven't considered' you are having an intelligent discussion instead of just burning the developers to the ground for missing some piece of information.
You might still come to the conclusion the devs are dumb, but at the very least you have made a good impression by not barging in like you know better than the people that have probably spent a lot more time with the problem. Step one is showing that you understand the domain, and realistically, quite a few times you won't even get to the next step of asking whether they considered a factor that went unmentioned, since you've missed critical information in your assessment of the problem.
To summarize: Interview the devs about their decision processes and the domain. Show you understand, and repeat the problem back to them in your own words. If they agree with your version, then and only then ask about things you think they missed, or decisions you still can't comprehend given your information. Reduce your ego, as hard a task as that might be.
As I said, I already spent too much time trying to understand their reasoning. In the end I just couldn’t, and I really tried, avoid the conclusion that they were incompetent. And I failed, even though I really tried, to present my criticism in a way that didn’t make my conclusion obvious.
I really, really don’t like making people feel stupid.
Good, that is already half the battle. Not jumping to the conclusion that the others must be incompetent can be more difficult than it sounds, and judging by your comment it looks like you have that down.
Were you able to ask the devs directly about their reasoning? Asking them about certain decisions, or trying to get them to explain the thought process and repeating it back to them in your own words is an incredibly important step. You might not agree with them at all, but the part of what your own ideas are is parked at that stage. Then, once you've confirmed their thought process, and they agree to your version of it, is the point to ask about improvements or different strategies that you see. 'Would there be any drawbacks to [your approach], because I think it would provide benefit [x], [y], and [z]' is a great point to start off from once you have that confirmation on your version of their thought process.
Now, if you don't have any access to the original devs it will become much more difficult to try this process. Best you can probably do is try and see if you can find a person that is willing to play devils advocate, or working backwards from your reasoning to see if there is any knowledge that when eliminated from the thought process will make you arrive to the conclusion of the original devs.
I did interview some of the devs about their reasoning, and they kind of admitted that they probably had screwed up. The problem is the "tech-lead" that claims that he has 20 years [sic] of .NET experience, but can't implement the strategy pattern correctly, but most importantly doesn't understand when and how to use it, which is evident by him hardcoding the "strategies" in the calling methods. He also has six layers before above dapper (no exageration, I have counted them) of classes for a simple stored procedure call. One of the problem is that five of those classes don't add any functionality, since they just pass through the string with the name of the stored procedure and the arguments. "This is how it done", is the answer I get when I question the wisdom of all the empty classes, and then he walks around and telling other people that I don't understand OOP.
After failing in my attempts to be transferred to an other team I'm sending out my resumé.
If you are able to summarize the problem in such a way that the developers say 'That is right', and they are not correcting you further on your understanding of the problem, then any criticism from your side is not as much of an attack. By framing it like 'I might be missing some context here, I think X, Y, and Z were your reasons for choosing this approach, but I think there is a factor F you haven't considered' you are having an intelligent discussion instead of just burning the developers to the ground for missing some piece of information.
You might still come to the conclusion the devs are dumb, but at the very least you have made a good impression by not barging in like you know better than the people that have probably spent a lot more time with the problem. Step one is showing that you understand the domain, and realistically, quite a few times you won't even get to the next step of asking whether they considered a factor that went unmentioned, since you've missed critical information in your assessment of the problem.
To summarize: Interview the devs about their decision processes and the domain. Show you understand, and repeat the problem back to them in your own words. If they agree with your version, then and only then ask about things you think they missed, or decisions you still can't comprehend given your information. Reduce your ego, as hard a task as that might be.