None of the things you mentioned are universal truths, and at least one is an outright error (“hydration errors” are a cost of using React, not something anyone else needs to worry about). There’s some truth here but you’d need to rewrite your comment to think about the kind of site you’re building, the different categories of data you work with, and how you’re hosting it. You also want to think about the advantages of SSR like much faster initial visits, better error handling, and better data locality. 

As a simple example, think about your first point about server size: if memory usage is driven by the actual content then you’re paying the cost of processing it either way —  if I have to search 20GB of data to get that first page of results, the expensive part affecting server provisioning is that query, not whether I’m packing the results into JSON or HTML. If it’s public content, the cost in most cases is zero because it’s cached and so SSR is a lot faster because it doesn’t need a few MB of JS to load before it makes that API call. 

Those network round-trips matter a lot more than people think: they ensure that visitors have a slower first experience for a CSR and if anything goes wrong, the site just doesn’t work (exacerbated by frequently-changing bundles taking longer to load and invalidating caches). They also mean you’re paying some costs more often: if I hit a 2000s monolith, I pay the logging, authentication, feature flag, etc. costs once per page but I have to do that on every API call so there’s an interesting balance between overhead costs and how well you can mask them because a CSR can make some non-core requests asynchronously after the basic functionality has loaded. Again, this isn’t a simple win for either model but something to evaluate for your particular application. 

This isn’t a new problem by any means but I still see it on a near-daily basis, and those sites which underperform a 2000s Java app are always React sites when I look. Last week I helped a local non-profit with their donation page which a) had no dynamic behavior (just a form) and b) kept the UI visible but not functional for about a minute while a ton of JS ran. This is not an improvement. 

It’s also not the 2000s anymore and so we don’t need to think about huge app servers when it’s just as likely to be something like a Lambda or autoscaled container so we’re not paying for capacity we don’t use and we can scale up or down easily. That starts getting interesting trade offs like how much faster your servers are than the average visitor’s device, especially when you factor in internal vs. internet latency and whether your API allows that CSR to be as efficient when selecting the data it needs as a service running inside your application environment can be (e.g.  I can cache things in my service which I can’t do in a CSR because I can’t have the client do access control). 

This is especially interesting when you think about options we didn’t have 20 years ago like edge processing. If I’m, say, NYTimes.com I can generate my entire complex page and let the CDN cache it because it has a function which will fill in the only non-cacheable element, the box which has my account details. Again, different apps have different needs but this capability allows you to have the efficiency wins of edge caching without having to shift all of the work to the client at the cost of lower performance, less consistency, and more difficult debugging. 

It’s also not the case that we have to write JavaScript on the server side, and you can easily see your claimed order of magnitude RAM reduction by using a leaner language than something like Next. A CSR can switch frameworks but not languages, so once you’re down that path you’re probably going to keep paying the overhead costs because it’s cheaper than rearchitecting. A similar concept applies strictly on the client side: React’s vDOM has a hefty performance cost but switching is hard so most people keep paying it, especially since their users don’t charge them for CPU/RAM so it’s less visible.