This approach and separation of concerns also means that building e.g. REST or GraphQL APIs on top of your application is simple, as your web framework has no say in how the data is actually structured or queried.
I think there is a heavy if unconscious bias among web developers now that the “one true way” to build web apps is to take the same methodologies and frameworks from Facebook and Google usually.
I’m obviously not the first person to point this out but trying to replicate the software development processes of some of the largest companies in the world is in no way correlated with a better anything (user experience, dev experience, code, time to market etc).
In fact I would take it further and say that there are a not insignificant number of new developers especially from the dev boot camp style pipelines who literally don’t even know how to build anything without reaching for one of these tools. We saw the same thing with people reaching for Bootstrap or now Tailwind for a long time and not knowing how to do anything outside of it. This isn’t to give them a hard time, I have been that kind of Stack overflow driven developer myself for a long time. I just think that maybe as an industry we have made some poor choices that have become gospel overtime and it might be worth revisiting that.
The benefit of building with a de-coupled JS frontend (SPA) and an API is that it can extended and adapted far easier than using server-delivered HTML.
If you have an API that delivers JSON/Protobuf/whatever, you can easily make new interfaces to that backend. If you are currently delivering a web app in HTML/JS, but decide you want a native Mac/iOS app written in Swift, you'll just end up building an API anyway.
Sure, there are plenty of websites that wont ever need additional interfaces, but if your goal is to make an app that can easily have new interfaces added to the mix, de-coupling is the way to start in my opinion.