Thank you for taking the time to read my article and write yours. I disagree with a large part but you definitely do have a few good points.
In general, I think your argument suffers from what I call solution probleming (as opposed to problem solving) which basically boils down to “I have this solution so let me find some benefits it has”. For example, it’s true that an SPA allows you to build your UI from components but the same is possible on the server-side (more on that in a minute). Solution probleming may solve these problems but not necessarily in the best way.
I think part of the trouble stems from confusing problems with solutions. This is best illustrated in your closing section where you say “[…] they solved the major problems all large applications had solved before: component system on the client”. “component system on the client” is never a problem. It could be a solution to a problem. The problem could be messy code (slower pace of development, more bugs), difficulty in on-boarding new developers (higher ramp-up time, diverts seniors’ attention). You need to diagnose the problem first and come up with a solution second. The solution might be an SPA but from my experience it’s very unlikely.
Let me comment on the arguments you make.
Components. Extracting helpers and partials (I assume that’s what you mean by “string splitting”) may be the best solution in many (not all) cases. When it isn’t then you can implement server-side components: extract the relevant logic into a class and associated template. For example, in Trailblazer you can defined cells that are composed of server-side code, templates, and client-side assets. You also always have an option of using React just for the most complex parts. I have yet to see a logout button that benefits from being implemented as a React component.
Templating. Many templating systems are based on string interpolation but you can implement component-based systems as well. It seems your biggest issue with templates is they can grow in complexity which is definitely true. However, the root cause is poor development and has nothing to do with technical choices. If you convert a convoluted template into a React component then you will end up with a convoluted React component.
There’s a plethora of server-side techniques for managing this complexity from helpers, to partials, to components. I call them “server-side” but they’re really generic software development techniques for taming complexity and can be used in all circumstances.
Client-side Interactivity. I greatly encourage you to check out Turbolinks and Stimulus.js. The former can help you make the app feel snappier without abandoning the MPA architecture. The latter works great for interactive parts that shouldn’t result in a page load. It also solves the subscribe/unsubscribe issue you mentioned before (which also could be solved in other simple ways without building an SPA).
Storybook. Components aren’t architecture-level entities. You can use components (even React-based) in an MPA. There’s nothing preventing you from rendering server-side components in isolation. I think it’s true that SPA people are more component-focused but it’s about practices not tools.
Some other things you mentioned seem to be irrelevant to the discussion. For example, naming (always a good idea), competence (any project can be caused to fail by hiring a sufficiently incompetent team).
You definitely do do have a point in saying supporting a mobile app may tip the balance in favour of an SPA. My biggest gripe is many (most?) don’t do any kind of cost-benefit analysis to make business-driven decisions.
PS Maybe there’s a niche for a server-side component library?