Same reasons some people like their frontend or backend frameworks to have everything in one place, to have everything in one place.

I prefer to compose libraries that carry exactly the functionality I need, and pipe them together myself. But I'd be a fool if I didn't realize that most people start projects today via some sort of framework that promises (and probably does) a "battery-included" sort of solution, where most of the pieces you'll use have already been put together for you, and you just need to write models, controllers and views (but your framework might call them something else).

Because SSR has a couple of advantages depending on the use case.

The most obvious is SEO and being able to send HTML without any JavaScript.

Doing SSR is also simpler than a well made SPA, generally speaking. Your api can be reduced to post requests, or removed entirely. The routing and navigation is much simpler. Etc.

SEO can be achieved with SPA and without SSR. I wrote an article on this subject: https://hackernoon.com/single-page-application-dispelling-se...

Technically true but in practice many SPAs will suffer form lower lighthouse scores which will affect page rank. Of course, this is not the case for SPAs that were optimized from the start, but that is rarely the case in the real world.

SSR. It turns out most devs can write reliable SPAs so you need some sort of hybrid.