I agree. The problem is that striking that balance is hard. If you go all-in with an ORM then trying to backpedal and figure out at which point you went wrong becomes almost impossible and so now you have a tangled web of ORM queries and no clear path to untangling things.
Sure, but the balance is entirely context-dependent. But hey, I guess this is where all polemics fall down.
That said, where is the academic problem in refactoring into the db and decomposing ORM queries into straight SQL where necessary/desired? I'm not a Fortune 500 Systems Architect, but I'm under the impression that this is a fairly straightforward process. Now, management of the systems will necessarily incur extra complexity, but that's a second order effect that should be assessed in the decision process as part of the cost estimations. Extra technical debt, for sure.
So, choosing one is technically cheaper and more simple and maintainable. Choosing multiple may be faster (or, in many cases, "academically satisfying"), but more complex with a steeper learning curve. Be sure to hire the best of the best!
Not so simple. Every big enough place will be a disjointed mess of cross-cutting concerns. The ORM (usually another custom mess on top of some open source thing) ends up being owned by everyone and in effect ends up being owned by no one. So then you end up going around asking each team in turn to fix stuff but each team consists of domain experts and not ORM/SQL experts so no one does anything. So then you bring in ORM/SQL experts but they don't have any domain knowledge so they just chip away at the edges and end up making no improvements and you still are stuck with an ORM nightmare.
The bottleneck in fixing technical things is never the technical stuff. After all, most of this stuff is 70s tech to begin with and the science has been worked out by much smarter people already. The social stuff on the other hand is a different matter entirely and once you're in an ORM quagmire it is impossible to get out.
