This particular one (the level where business logic lives) isn't that sort of "poor experience", in my view. (The other example you pulled out about long names,

This particular one (the level where business logic lives) isn't that sort of "poor experience", in my view. (The other example you pulled out about long names, yeah I don't much care either way about that one.) But the phenomenon you're highlighting is also real. Sometimes rules / guidelines / "best practices" are arbitrary and useless. Other times they're extremely helpful. There isn't any hard and fast rule to differentiate between the two cases. The best we can do is have humans run projects using their judgment. Again, using this "should we separate domain logic from routing / controller logic" example: It's true that some projects are never successful enough for this to matter. But what I look for are opportunities to do things that have very little cost, which also scale well if the project is successful and grows. I think this is one of those things. It is trivial to separate concerns. I would even say it makes it easier to write the code that way; I don't want to be thinking about routing and wen service related cruft when I'm trying to implement some business logic correctly. It makes it harder to test and harder to write, in my view. And I think it also scaling into a large project better is also a big bonus. But I certainly don't think my experiences are the only ones that anyone has. I think I'm right about this, but there are also lots of people I respect who disagree with me and they think they're right about the opposite view. Unfortunately there isn't some divine referee to tell us who is actually right :)