Yes. This is why I use Redux. All the other stuff like reproducibility, state persistence, and devtools are just icing on the cake.
Redux heavily encourages architectures where the vast majority of your app has no knowledge of how data is stored, fetched, or updated. I purposely architect everything so that Redux would be easy to remove -- not that I actually plan on doing it, but it's a good litmus test that my architecture is properly data-agnostic. The end outcome is that the majority of the code is "pure" -- that is reusable, composable, and predictable. It's also immediately obvious which code actually touches state (namely actions, reducers, and containers).
"Overhyped" implies that its popularity is not worth its value. It's clear that it has proven its value to a majority of developers working with React. Especially as applications grow larger, I've found that using Redux provides an intuitive pattern for sane state management.
It does have its pain points (verbosity, async actions) but there's a plethora of libraries one could choose from, depending on need and preference. Since the core functions are so simple, they can be adapted as needed - for example, in a recent project I wrote a wrapper (~20 lines) to extend actions and reducers with namespaces.
An additional advantage of Redux, I think, is that it's becoming widely adopted, so when I look at an open-source codebase built on React + Redux, it's so easy to understand the application architecture.
That's my point, I believe a library should not imply architecture.
