> By showing you understand the constraints the developers were under
And when you take this approach, maybe all of you together will discover that some of those constraints are the things you'd like to change
I really, really don’t like making people feel stupid.
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.
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.