I know this is a popular line of thought, but as someone who really measures things, it doesn't match my experience when it comes to web server frameworks.
In web applications, apart from glaring mistakes such as N+1 queries, pretty much every bottleneck I had in production was due to slow serialisation, slow database abstraction or excessive CPU/memory usage due to language/framework. Also had issues caused by initialisation time. Saving 200ms or 300ms on each request can give you better user experience.
For growing startups, having a fast web framework gives you the choice to postpone doing complex horizontal-scaling for months, or even years. This saves money on the sort term and allows you to keep growing their products without having to worry about other things. The database can scale vertically in the meantime.
As for large tech companies: at my previous workplace there were two migrations in the span of two years because of performance issues. Hundreds of developers collectively agreed on changing the tech twice because of framework bottlenecks.
Of course you shouldn't go straight into a C++ framework when Rails becomes too slow for you, but people should know the tradeoffs of the framework they're using.
Developer velocity matters way more than the framework as long as the framework allows for horizontal scaling. You don't have to use it, but it should be there and it should be easy to use. Depending on your goals, one should be writing a system that horizontally scales after the first major prototype. Then push the horizontal scaling tests into your CI/CD pipeline and dev locally as if your cluster scaled down to one node.
Nice of you to mention developer velocity: it is extremely important, and it's also severely impacted by things that depend on the framework having good performance, such as initialisation time, development-time performance (it's important to have a quick feedback loop), time required to run individual tests (important for TDD), time required to run the whole test suite (running it often saves developers time during refactoring), time required to compile assets, time for the CI/CD to run (important to allow quick and safe bug fixes and a fast process), etc.
Once your app stops being trivial, those things start adding up and people start talking about migrating to something else, breaking the app into microservices, or developing in-house tooling. All those things cost money. It might take a few months but it happens. And I've seen over and over.
Also, having horizontal scaling is definitely not easy for non-trivial apps. It costs money to the company, might require extra employees, and might put a hold on new features. And horizontal scaling doesn't help you with performance time or developer velocity.
Also please keep in mind that performance and developer velocity are not at odds. Most of today's "fast" frameworks are quite good when it comes to developer velocity: ASP.NET Core for instance is #6 on the Techempower framework and is incredibly productive.
Is this one of those RomComs where we are screaming at each other in agreement?
Horizontal scaling of course isn't binary and using a remote state store, preferably with CRDTs or strong consistency will allow _most_ applications to remove a spof and single node perf from dominating.
Everything you said is spot on, except for your dismissal that horizontal scaling should be first class. It might have been hard before, but we no longer have an excuse. Store your state in a modern distributed store.
> Developer velocity matters way more than the framework as long as the framework allows for horizontal scaling
I disagree with that. Both because developer velocity is not unrelated to framework performance, and because horizontal scaling is not a silver bullet that will magically solve the performance issues related to framework code.
In web applications, apart from glaring mistakes such as N+1 queries, pretty much every bottleneck I had in production was due to slow serialisation, slow database abstraction or excessive CPU/memory usage due to language/framework. Also had issues caused by initialisation time. Saving 200ms or 300ms on each request can give you better user experience.
For growing startups, having a fast web framework gives you the choice to postpone doing complex horizontal-scaling for months, or even years. This saves money on the sort term and allows you to keep growing their products without having to worry about other things. The database can scale vertically in the meantime.
As for large tech companies: at my previous workplace there were two migrations in the span of two years because of performance issues. Hundreds of developers collectively agreed on changing the tech twice because of framework bottlenecks.
Of course you shouldn't go straight into a C++ framework when Rails becomes too slow for you, but people should know the tradeoffs of the framework they're using.