Before SSR (unless you were using PHP I guess) you had to ship a shell of a site with all the conditionals being decided only AFTER the browser has gotten all the HTML + JS pulled down. If you need to make any API calls, you've delayed rendering by hundreds of milliseconds or worse (round trip to your server)
With SSR, those round trips to the server could be down to single-digit milliseconds assuming your frontend server is in the same datacenter as your backend. Plus you send HTML that has actual content to be rendered right away.
A truly functional pageload can go from seconds to milliseconds, and you're transferring less data over the wire. Better all around at the expense of running a React Server instead of a static file host.
SSR can be a game-changer in domains like e-commerce. But completely useless for some other use case.
RSC advantages are a bit more complex to explain, because even a simple portfolio website would benefit from it. Contrary to the common belief created by long-term ReactJS dev, RSC simplifies a lot of the logic. Adapting existing code to RSC can be quite a mess and RSC is a big change of mindset for anybody used to ReactJS.
I think they have a point, before cgi-bin it was almost impossible to have a real web application. It took a decade for server-side rendering to fall out of favour. Flash websites and Gmail starting to become seriously interactive in the mid 2000s were the start of frontend-first web applications, but even those relied on the backend to provide them with an initial data set to make performance usable.
No, they were not. They required a lot more round-trips to the server though, and rendering the results was a lot harder. But if you think of a browser as an intelligent terminal there is no reason why you couldn't run the application server side and display the UI locally, that's just a matter of defining some extra primitives. Graphical terminals were made first in the 60's or so.
