Current gen frameworks can totally consume the api on server and spit out perfectly normal html to browser just like normal mpa. However this depends on whether you have a competent ops team that is capable to deploy something other than static html. And not having that is the reason you choose spa at first place in a lot of times.
It solves the problem that your ops team sucks and can't deploy anything other than static html while you are required to make a site with proper custom url (and custom content base on url). And to me the quality of ops team is a REAL problem. If it isn't a problem for you then you are just too lucky (I'd envy you ;_;) or never doing any web development.
To be honest, server side rendering is always the king regard of performance. A properly optimized static html generator can make you see the page under 0.5s after you click the link even under most awful network. And it isn't even enough for most spa to download the javascript alone (it will at least need 3 rtt to see basic layouts, one time html, one time js, the js load the images and style)
What I'm saying is that problem might be solved (or solvable) now, e.g. with stuff like Phoenix or NextJS, but it wasn't solved when SPAs were invented.
SPA was never made to solve those problems in my opinion. They are basically unfortunate side effects that introduced when SPA was made to resolve it's original targets. (And without SPA, we would probably never know mess with routes is so damn problematic.)
The problem was: can we make the same data APIs to serve the web and mobile apps?