This is where we a missing the middle ground in the debate.
I do not consider a server rendered page that then uses HTMX (or "just" jQuery) to do partial refreshes or given areas of interactivity to be a SPA.
So yes I can have my MPA and I can have partial content refresh and that does not require going all in on SPA frameworks.
We desperately need better terminology around this stuff and the willingness to engage in nuance and see these it as a broad spectrum of various approaches you can mix 'n' match—sometimes all in the same project! Saying "oh this app's MPA, oh that app's SPA" will totally lead n00bs astray who aren't familiar with the production-level nuances involved.
Not because there are tons of users running around with JS turned off, but because every page load is running without JS until the JS finishes executing successfully ( as noted by many others ).
Why not? HTMX is itself a framework right? The distinction between SPA and MPA that the article gives (and that I agree with) is that MPA's delegate routing and page transitions to the browser. This naturally leads to less control (which makes the best case MPA worse than SPA), but also less complexity (which makes the average case MPA better than SPA)
Usually the only gain is that you don't have to reload and re-parse all the javascript that is there for doing partial refreshes.
With SPA frameworks you can deliver pages that can be accessed by the user (rather than just a single entry point). The difference becomes how the developer decides to build the application. Do they load all of the apps data on the first page load or do they retrieve it as the user browses around?