This is the crux of where I always landed on whether to render on the server or in the client.

Render where the state lives. If a piece of state is stored on the server, and the server will have to be notified when it changes, rendee HTML there. For any part of the UI that really is temporary state that only lives in the client, just render that piece (or changes to that piece) in the browser and leave the server out of it.

An all or nothing solution is rarely the right answer.

Many developers fail to notice how colored their perspectives are by a) nostalgia for the technical simplicity of web 1.0, b) the curse of expertise, and c) confirmation bias.

A website, just like any other application, exists to solve a problem. The right ratio of hassle/efficacy/reliability definitely isn't the same for every application, and often not even the same among different user groups. What developers consider to be a hassle or too complicated is dramatically different from most other groups. Doctors and children and mechanics and mechanical engineers and artists have more in common with the way they interact with software than any of those groups do with software developers. If you have a working mental model of what's happening behind each click, your perspective is totally different.

To a developer seeing a form submit and waiting for a return is a set of actions with a story behind it. We know what's happening. To a typical user, it's a period of flickering and flashing and waiting after they clicked on a button. There's no meaning to it-- they just compare the action of button A which changes screen state instantly, to button B which seemingly dicks around for a while until something happens. What about on slow connections or devices? It depends on what problem you're solving. If you serving up nearly static content, using an SPA is absurd. If you're doing something interactive, it's way worse to have constant reloads than use a -----properly designed----- SPA that loads once, uses local storage efficiently, and only makes small API calls to the server once its loaded. If an SPA has poor architecture or is a bad solution for the problem, the problem is the developer that made those decisions, not SPAs.

A 500% reduction in technical complexity is meaningless to most end users. If it comes at the expense of having to look at a page reload in between frequent operations, it's a big annoyance. Sure, I'd much rather put together a nice clean static site than do something dynamic, but what the hell is the point if it's not the best way for users to solve the problem they need it to solve?

Beyond that, I guarantee you there are many sites that 'just work' the way you'd expect a website to work and you'd have no idea they were SPAs. Making a proper SPA requires a lot more technical design and expertise than making a traditional site, and using a poorly made SPA is a WAY worse experience than using a poorly made static site. That makes it really easy to notice when one is bad, so it makes SPAs seem bad, generally, which is just not true.

For the same reason we can't leave all technical decisions up to designers, we can't leave all interaction decisions to developers. Obviously it will make development a lot easier and smoother if we do, but that's one of many factors, and quite often not the most important one.