well first there is a rule of thumb. everything that does not have isolated complexity in the state can and probably should be done as a classic SSR (server side rendering). Isolated complexity means -> many different moving parts that do different things. For example facebooks timeline, notifications and chats. These states are mainly connected via the layout, not their functionality. As they advance, the harder it gets to control them if those states are not isolated but accessed via even listeners.
The main reason for not throwing a state-component rendering approach onto everything .... it's way less complex just using a SSR template and with complex I don't necessarily mean hard. I mean the amount of parts that have to work together to achieve an outcome, hence the amount of work needed to combine them.
You can however use something like nextJS and write react components ... I leave this up to you.
But in my opinion simplicity should dominate, writing a blog in angular and react has no real benefit, besides making things overly complex. And you can pat yourself on the shoulder. Which is nothing bad, it's just not really beneficial.
However adding certain components to enhance your SSR with a client side engine can be beneficial. For example a searchbar with interactive filters, here a component-based / state oriented design is better than event based design (we just hook up, event-listeners with the content, we lose control of the state and people tend to overload dom events) if we think about it from a JS perspective.
The reason here is simple, if the (search-bar) component has an internal state, it's easier to control than having everyone trying to hook up your elements with events. So if we got 5 filter settings with, I don't know, 3 drop-downs and 1 multi-select this state is way easier to handle if the state is represented not only in the meta markup but is the markup is the result of our state on the client-side.
That is my experience after working with JS and other languages for a long time now.
advantage
disadvantages
And I won't go into the eco system issues because tens of thousands of packages means a lot of shitty packages that won't get maintained in the longterm.
Meanwhile django, php is pretty stable esp because it's not so hyped at the moment. And I won't even go into the state handling problems, Higher order Components and all those things.
These techs are really cool and can be a lot of fun, but they also need work and understanding. Both of them need time. I enjoy working with react / redux / typescript still having a PHP backend. But I have an application with a rather complex frontend that interacts with it self.
If you don't need a lot of isolate moving parts -> stick with a backend system that just delivers plain old HTML, GZIP it use HTTP2 and the right defer, async script tags and utilizes all the existing technologies.
Less work, same result. Which probably means less bugs and more focus on your needed parts.
If bad comes to worse and you find out you want a react component in your parts -> just create the normal Form in the backend, give it a unique id and hook in the react component over the form, so if JS is not working you still have the normal form not as pretty but still fully functional and if it's working you can have a highly interactive search with live reload.
That's called progressive enhancement and that's a robust way to build web-pages. You still have your fun but only as an add-on not your base.
stuff ;)