I think that, in 2024, a lot of these problems aren't as bad as they once were, but when this article was written in 2016, SPAs really were a mess. Since then, people have mostly solved the URL problem and the back-button problem, and I think that if your organization has the headcount to support it, there are advantages to having the kind of very clean separation between your backend and your user interface that an SPA can provide. For instance, They can be developed by different teams, on different release schedules. Or, you can replatform your backend without rewriting your frontend.
Even so, I kind of wish that most websites still used old-school server-rendered HTML. I still run into all kinds of glitches that just could not possibly happen on a server-rendered site. As an example, I like to visit the Deutsche Welle website to catch up on European news stories that don't make their way to the US, and sometimes their site just flat-out doesn't load, because of some caching problem that I don't care about, because it isn't my problem as someone who just wants to read the news. Since the best DW's SPA architecture can possibly do is to make it look like server-rendered HTML, it's just nothing but downside to me personally. It might make sense for Deutsche Welle itself, but I don't work for DW, and I don't get paid to care about their problems.
In the end, I think the overall message of the article still resonates in 2024, even if it doesn't resonate as strongly now as it did when it was written. I think SPAs are good technology when they are used in the right way for the right reasons. But there's a kind of dogma surrounding heavyweight JavaScript frameworks, and I think it pays to be a little skeptical as a result.