Making initial page loads significantly faster, especially on intermittent mobile connections (which is an extremely common situation often underestimated by web developers) is worth a little bit of complexity, yes. And the entire point of these frameworks is to abstract away most of that complexity.
That's the elevator pitch, but as someone with a middle-tier Android phone and in an area with not that stable mobile connection, those supposely "optimized" pages work much worse than plain old HTML. It's even funny how my phone struggles to even render the home pages of these projects.
Developers always find ways to down-compensate gains due to Moore's law and its infrastructure equivalents.
Of course it's slower than plain HTML being delivered from the server. That's not what we're comparing to, and frankly if that approach fits the needs of your project then go ahead and use it.
The real comparison point is client rendered SPAs, which is the status quo in web app development that SSR frameworks are competing with. If that's your starting point, SSR is a strict optimization and a significant improvement for almost all usecases besides internal admin tools that are only meant to be used on desktop.
Not OP, but I think the point might be that we get served more and more SPAs weighting millions of lines of JS for anything and everything, because it's trendy in a resumé-driven industry, while overlooking the end-users needs and constraints
That's not a relevant or useful point at all. Obviously there will always be people using the wrong solutions for their problems. Doesn't mean that other people don't have perfectly valid problems that need a solution.
