With SPA, all your backend has to do is spit out data and sometimes validate it, leaving your front-end completely in charge of presentation and user interaction. You can even have completely separate teams working on it. It feels a lot less complicated than the alternative.
Yes Conway's Law:
https://en.wikipedia.org/wiki/Conway%27s_law
The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.
That "backend" vs. "frontend" split is entirely artificial. That code you would run server-side to convert your data into a fully-rendered page is still very much part of your "frontend" organizationally, even though it might be hosted on the server.
(Strictly speaking you can have a web service that's purely about spitting out raw data in a form that other organizations can use, but that's the kind of thing that Semantic Web and Linked Data standards are intended to address. Not something that your garden-variety website has to be concerned with.)
OTOH you now need an API and glue code in the frontend. I'm not saying it's not worth it but it's definitely more work.
That's a debate spanning multiple decades. Your last sentence is not true all the time.