If it takes 5 API calls to populate your page, do you want to make 5 round-trip responses to where you user is, or 5 within the same datacenter and 1 to your user? If the answer is that it doesn’t make a difference, then you don’t need these tools.
I think that could be a good argument for a BFF, not necessarily for a SSR app. IMO the only times it makes sense to pre-render your app is when initial loading time and/or SEO are of utmost importance.
You can run the SSR server in the same process, and the main benefit is that the client is a lot thinner (only needs to swap in HTML, no need to render anything).
Depending on the server framework, it should be perfectly possible to e.g. have uniform routes for JSON data and HTML hypermedia, although you do need to be careful with churn in such cases; you don't want a website redesign to break your native app. The HTMX author has an essay describing a solution: https://htmx.org/essays/splitting-your-apis/. Essentially, just implement two APIs! Since you can do this in a single backend (e.g. Django project) the amount of duplicate code should remain fairly limited anyway.
Also, many modern SPAs are highly complex in order to do things that don't require any work in a hypermedia application. For example, if you want JS-disabled clients to be able to view your page, you need to run a copy of the client on the server, necessitating a full JS runtime there (bad if you're not using server-side JS already!). And then you also need complex hydration logic so that it gracefully transitions to a full SPA. Plus this solution sucks if you want to use something other than JS on the backend.
With hypermedia tools like HTMX it is generally way easier to achieve progressive enhancement (although it will still require some thought, see e.g. https://htmx.org/docs/#progressive_enhancement)
