Of course SPAs have their problems and building a server rendered application is easier. That should be a no brainer. You introduce a new language and a new framework + communication between 2 systems. Plus, you introduce state.
But I feel like the article misrepresents some of the complexities involved in building an SPA.
You will need design carefully your serialization logic to optimize the database queries and keep things performant.
As if you didn’t need to do with server side rendering. You need to be equally careful when rendering a whole page with all of that data (where otherwise you’d retrieve part from an API). Which especially in Rails thanks to lazy loading ™ can be hell.
The post also kind of glosses over GraphQL (imo) and just how much it helps with the problem of fetching the right data. For instance with Relay each component can specify the data it needs and it will all be composed into one big query (granted I never did this in practice, so far).
As for initial load time, it depends on how much of your page is static. In an SPA or well JAM stack where you pre render the markup and then hydrate your first render is much faster because you need no database queries serving the initial page + the static HTML can be stored in a CDN close to where your users are.
Of course that’s not always great (looking at you reddit where I see a useless page and then it loads posts for like 5 seconds).
On the other hand, for apps that I expect to spend a significant of time in (think: a game) - I don’t really mind an increased initial load time vs. the much faster interactions later. If the data is already loaded/cached then the interactions can be pretty much instant, as no server round trip is needed at all.
I’m also mildly unhappy with some of the criticism in the post is just presented as “this is bad” without much reasoning:
On the other hand, I strongly dislike the Flux/Redux camp. I have seen so many smart people adopting it that I have made an effort to study and understand it, multiple times. I can’t avoid ending up shaking my head in disbelief when I see the code. I don’t see myself writing code following such pattern and being moderately happy at the same time.
Finally, I have a difficult time accepting that mixing HTML and CSS in components full of javascript logic is a good idea. I understand the problem this solves, but the issues it introduces don’t make this approach worth it, in my opinion.
The whole section (for me) pretty much summarizes to: I dislike the arguably most popular approach for building SPAs (the react way) without really specifying what’s bad about it other than mixing HTML, CSS and JS.
The last kicker for me is betting on stimulus that is only “months old” after saying that every yea new frameworks appear and that it’s a problem because you have to live with your choices for so long 
It might also be worth mentioning some time that if you already have an API ready to roll, development of a native app (mobile!) is easier, albeit I think lots of mobile apps would have been better off by just staying web pages. But it also, if you choose so, allows 3rd party developers to integrate with your platform easier.
Funnily enough, through “trusted web activities” Progressive Web Apps (special SPAs) can now apparently be published to the Android App Store - Google Docs. Which for certain kind of apps makes SPAs even more appealing to me, however we’ll have to see how this does in practice (this is from a couple of weeks ago).
Contrary to what you may now believe, I’m not some super SPA lover I just think the article misrepresents some of the trade-offs quite a bit. And that there are use cases for SPAs. I completely agree though that they are over used and people seem to severely underestimate good old server side rendering and how far it can take you. It highly depends on what you build though. Our app is mostly server rendered, but we have some parts where we need very fast interactions and rendering it server side might actually be more complicated (think someone editing a huge “document” were submitting the document for real triggers calculations that take quite a while). These parts are then SPA-ish in their use of front end frameworks, which I think is a good tradeoff often, and also what Stimulus aims for to the best of my understanding.
? I think the scroll tries to be fancy and remember that last thing you read or something like that. For sure the implementation can be wonky. As with all things theres a place for it and as with all things people take it to the extreme. For the record, I typically take advantage of SPA style functionality behind guarded endpoints. Pages such as landing pages, marketing pages etc. I try to keep as static as possible because, and I quote
I also think we agree in general, it’s much easier to disagree on details after all 
