I could put it another way. Some people who are comfortable with complexity don't actually come up with the simplest solutions, and instead come up with more co

I could put it another way. Some people who are comfortable with complexity don't actually come up with the simplest solutions, and instead come up with more complex solutions because they themselves find them relatively simple. It's a pattern I've seen in talented engineers with less experience. And on your question, I don't think it's the case. If it were, then there would be little excuse to use Ruby over Java, or Java over C++ / Rust / etc. In the same way as we pay a performance penalty in return for productivity when we use an expressive, high-level language, we pay a performance penalty for maintainable code with clear abstraction boundaries. Efficiencies, when they must be found, often come through vertical integration that burrows through abstraction layers. Ideally we build our architectures so that we can scale out rather than up, for both hardware (easy) but also the team (the much tighter constraint - aiming for fungibility and elasticity of labour). If we get to the size of a Google or FB, then we can worry about squeezing out more profit, but first comes growth, and that means product, which means features.