I feel like this line of thinking is very analogous to the whole microservice craze -- you shouldn't need to introduce a network boundary to write well architected software. There's no reason you can't have a clear separation of concerns in a server side rendered application.
And "there's no reason you can't, if you wanted" is a far cry from "sure, the work is already done."
For example, something as simple as having a server-side rendered forum built with your favorite back-end language and now you want to build a client for it (web, iOS, Android).
That basically means massive duplication as you create a json interface boundary.
Yeah, you were already passing a { user, topic, posts } object to the template, so you can just serialize it your json api, right? But you can't because when you wrote that code, you knew the data never left the process. You didn't need to scrub the user.password_digest. Adding an api on top of an existing system is a lot of work no matter how much you hand wave about "well architected software."
But forget over the air network boundary. How about just wanting to implement the view layer of your Rails app with Go one day? How exactly would a "well architected" Rails app help you out?
The truth is that one reason that SSRs are simpler is because they are monoliths which spares you from certain classes of concerns. That's the trade-off you have to pay for if you want to cleave the monolith one day.
It sounds like you're assuming the SSR is not well architected and then using that assumption to prove your point. It's pretty easy to have an API layer interal to your application -- have your view templates consume that API. No reason you have to have your view templates across the network, written in another language.
No, what I would say instead is that 90%+ of SSR apps aren't architected like that, so I would accuse you of the same thing: that you're using "well architected" to describe what's actually an exotic configuration that nobody refers to when they talk about SSR, basically creating microservices on localhost that hit your own network stack which is a premature abstraction for most cases that I thought you just got done lambasting in your OP.
Who said anything about microservices on the local network stack? You don't need to do that to separate the layers; just have them be separate logical layers in your application. This is common enough that I almost think we're talking about different things: people have written APIs and SSR apps for much, much longer than SPAs have been around.
I agree 100%... The network boundry is in fact arbitrary. There are all sorts of similar hardware boundries in any computer system which we trust the OS, framework, language, etc to abstract away for us. For example how often do we think about where an Array is stored? It could anywhere from Highspeed cache to swapped out on disk. Likewise the client-server boundry for most of coding should be invisible.
