I don't think CSR is going anywhere, mainly thanks to Conway's Law.
Specifically, it depends on context. How big is the app? How many people are involved in building it?
As with many things, separation of front and back ends grew out of web-scale companies and products. If you're buiding Facebook or Spotify or Gmail, then you need a way to partition your app - because you need to partition your people. Humans need structure, we don't deal well with single teams of multiple hundreds.
Many apps don't fit that model. Lots of apps - e.g. business internal apps - might target at most small 100s of users and justify a dev team of < 10. In that world, separation of front end and back end devs & stacks is a disadvantage. Single language, single build apps mean less technical surface for the team to cover. Which means each person can more flexibly turn their hand to the requirements. Most people can do most things end to end. Features are business-driven and end to end. A single PR can deliver a meaningful piece of user-accessible value. There's no unionised demarcation.
None of which says "separate UI & back end is universally wrong". But it's not universally right either. As is so often the case, it degenerates into a discussion that is technical and absolute when the underlying forces are organisational and relative.
The very first step in creating this separation is to define an API that is implemented and operated by backend devs and used by frontend devs. Once you have done that, you have achieved all the clarity that is necessary or possible.
Whether or not some parts of the frontend are executed on the server-side shouldn't matter for the question of who has responsibility for what.
Perhaps it's more about the ease of hiring for different skillsets. If frontend is synonymous with client-side and backend is synonymous with server-side, it makes life easier for HR and recruiters.
If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. With client-side rendering there's usually expectation of some monolith project using the single framework.
It also gets you vastly more choice in language/tooling/etc, even allowing a mixture of different ones, which is what attracts me to SSR. Of course this may change in the future once WebAssembly has had most of the DOM interop overhead optimized away, bringing this freedom to CSR.
1. Written in different languages.
2. Completely different deployment paths.
3. Causing completely different ways of scaling.
4. Focus on UI and UX is a very different mindset, with often some people preferring it to be a focus of their work, or not.
I love the 'CHAMP' stack, which stands for CSS, HTML, Apache, MySQL and PHP. ;) Clear separation between frontend and backend.
I'm almost happy that I started webdev in the 90's. This 'ancient' technology is still going strong, with websites and a whole lot of webapps.
You say this as if it is necessarily good, but I disagree and would even say it's actually a hindrance for many teams. It often adds inefficiences, increases costs and makes planning and collaboration more difficult.
> the fact that you get an API by default with CSR is also nice
The vast majority of applications don't need an API.
Yes, and if a single team is doing both it adds another stack to master. This can be a pro or con depending on the size/organization of the team.