Uncle Bob does a bad job talking about trade-offs, but there's still value in stuff like SOLID. The problems start when people blindly obey or ignore design principles. Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
The trouble with SOLID is that it's mainly an artifact of old languages and paradigms. 3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time. So what's the value here? Single responsibility? That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.…
Except I see people getting it wrong constantly, even in the comments here. Its not about keeping code together that's related in functionality, this about keeping code separate by stake holder. For example, if you have two bosses that keep asking for changes related to their departments, you keep their relevant code separate, so when you have to keep updating it for one boss, you don't break the code related to the other boss, and vice versa.
Does it work? I don't know, never been in this situation.
https://en.wikipedia.org/wiki/Single-responsibility_principl...