That's also my conclusion after toying a bit with those frameworks. You want to use them for specific pages ressembling applications, but you still want the main structure of your frontend to be defined server-side, using the most standard technology.
This lets you split your interface into more isolated components, and makes you free to use different framework depending on the type of interaction your page needs, as well as be able to update your site progressively.
yeah, for most web apps that are primarily regular CRUD+routing interfaces, you can/should use SPA tech to progressively enhance your more advanced controls. There are cases where it makes sense to build a whole SPA (I'm working on an in-browser editor that wouldn't work very well as a backend app, for example) but the vast majority of cases where React is used, it just adds complexity and challenge.
React/Redux hasn't been around long enough for its best practices to solidify in the general industry so you'll often find that companies that picked up React have a hodge-podge of incorrectly used technologies included because they didn't know the use case for Thunks vs Sagas, how to use Reselect correctly, whether to store any given state in Redux or a Container, and so on.
This lets you split your interface into more isolated components, and makes you free to use different framework depending on the type of interaction your page needs, as well as be able to update your site progressively.