Why use React server side rendering

Load Times

A rendered view of the application can be delivered in the response of the initial HTTP request. In a traditional single page web app, the first request would come back, the browser would parse the HTML, then make subsequent requests for the scripts — which would eventually render the page. Those requests will still happen, but they won't ever get in the way of the user seeing the initial data.

This doesn't make much difference on quick internet connections, but for users on mobiles in low network coverage areas, this initial rendering of data can make apps render 20-30 seconds faster.

Views with static data can also be cached at a network level, meaning that a rendered view of a React application can be served with very little computational overhead

SEO

When a search engine crawler arrives at a web page, the HTML is served and the static content is inspected and indexed. In a purely client side Javascript application, there is no static content. It is all created and injected dynamically once the appropriate scripts load and run.

Unlike React, most frameworks have no way of serialising their component graph to HTML and then reinflating it. They have to use a more convoluted approach, which often involves rendering their page in a headless browser at the server, then serving up that version whenever a crawler requests it.

React can just render the component tree to a HTML string from a server side JS environment such as Node.js, then serve that straight away. No need for headless browsers or extra complications.

Noscript

It also allows you to write applications which gracefully degrade and ultimately, can be used as thin clients. This means that the processing goes on at the server and the application can be used in a browser with Javascript disabled. Whether or not that's an important market to consider is a debate for another time.