I think there’s a bit too much “blaming the tool” going on here. Be reasonable about what you introduce into a software project. If it’s a bunch of CRUD you probably can wait to add a front-end framework. If you find yourself needing it for that one big feature where you have to implement drag-and-drop and a bunch of DOM manipulation, don’t rewrite your whole app, just tailor that one experience.
If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience.
Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.
Well, I think the main difficulty with SSR is you'd think it would be more of an incremental step. I don't think it's so much a "separation of concerns" issue (i.e. just having some of your presentation logic running on-server doesn't mean it's necessarily not isolated logic) as it is a "wow I have to rewrite significant parts of my application to take advantage of this" issue. Some frameworks definitely do a better job with this than others IMO, but not everybody wants to (or should) migrate their React app to NextJS (for example) just to get SSR.
If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience.
Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.