I don't have much to add to @Spivak's comprehensive response, except this one thing: IF we agree backend services should be freely developed in multiple langua

I don't have much to add to @Spivak's comprehensive response, except this one thing: IF we agree backend services should be freely developed in multiple languages with multiple frameworks or "middleware" as the needs of the problem dictate, THEN we pay for that flexibility through the total effort required to deploy, secure, operate, enhance and maintain the overall system. Engineering teams need to weigh the benefits vs the costs in that tradeoff. The good news is that the current wave of tooling is converging in a place where the so-called "system administrator" can express platform constraints in configuration or code that is visible to development, and likewise the developers can express the software requirements in configuration and code that is visible to ops. That transparency means (in principle, albeit imperfectly in practice) that conflicting needs surface more quickly and the team has access to the complete picture; therefore possible for the full team to learn from that view. In every startup I've run, the necessity to build and deliver quickly leads to a pragmatic choice of a subset of languages and frameworks. Narrowing assumptions allow the team to concentrate on optimizations (of staffing, of code, of process, of tooling) that tend to accelerate things overall. Is "pragmatic choice" a euphemism for "too many layers of intermediary getting in the way of progress"? I don't believe so. Any artist will be familiar with the necessity of constraints, e.g. "The enemy of art is the absence of limitation" (Orson Welles), "Art lives from constraints and dies from freedom" (da Vinci), "Man built most nobly when limitations were at their greatest" (Frank Lloyd Wright). I would submit - don't fight this tension as if it's an evil that needs to go away, but rather accept it as a necessary and even desirable limitation that you can use to your advantage.