To me, client-side rendering feels like an end-run around incompetent full-stack devs who don't know how to make server-side rendering fast. So why not throw a big blob of JS at the user (where their Core i7 machine and 16GB of RAM will munch through it), and on the backend, the requests go straight to the API team's tier (who know how to make APIs fast).

There are other advantages to server-side other than the specific professionals involved in the implementation.

Server rendered web applications are arguably easier to understand and debug as well. With something on the more extreme side of the house like Blazor, virtually 100% of the stack traces your users generate are directly actionable without having to dig through any javascript libraries or separate buckets of client state. You can directly breakpoint all client interactions and review relevant in-scope state to determine what is happening at all levels.

One could argue that this type of development experience would make it a lot easier to hire any arbitrary developer and make them productive on the product in a short amount of time. If you have to spend 2 weeks just explaining how your particular interpretation of React works relative to the rest of your contraption, I suspect you wont see the same kind of productivity gains.

This is completely subjective, but if you want reduced maintenance expenses then don’t rely on any third party library to do your job for you regardless of which side of the HTTP call it occurs. Most developers don’t use this nonsense to save time or reduce expenses. They use it because they cannot deliver without it regardless of the expenses. The “win” in that case is that developers are more easily interchangeable pieces with less reliance upon people who can directly read the code.