My experience (30 years in software, 25 in practicing architecture, MIT system architecture masters) tells me there is no such thing as abstractly “good” design. There are designs with negative consequences for sure, but “good” depends on the context: what are you building, safety/security requirements etc. Probably most importantly on the implementation team and it’s structure. A team of juniors will butcher your intricate design and Conway’s Law makes your software reflect the team.

It's about having most compromises be Not Totally Stupid and have the worst ones only be locally stupid. There is a big universe out there of compromises that fulfill those criteria. As you imply, a lot of the time it's more about constantly fighting for Less-Bad-and-avoiding-Dumb than about architecture as such.

Yeah, as I've been learning more about software design, it's become pretty clear there is no silver bullet. It would be nice though. I find it a bit overwhelming to try to find the best solution for a problem when there are so many different architectures and programming paradigms.

That being said, taking into account the requirements does eliminate quite a few of the options. Right now, I work on safety-critical embedded systems which requires us to make some decisions that would most likely be way different in other environments.