Let’s keep in mind that Redux was not the originator of the movement against local state. It simply got popular as one solution.
At the time Redux got popular, many, MANY people were being burnt silly by local state in other, non-React related frameworks. Backbone, Angular 1, you name it. Flux was a solution to it, but it was hard to use. Redux was a solution to both the local state problem and Flux.
But we’re in a period where more and more people are moving into frontend… a ton of these people have never felt that pain, or have never even shipped a frontend app. So they look at React/Redux, compare it to what they’re used to (which may be nothing if they’re new to dev in general, but it could be their Java API, or some Rails full stack app), and it looks absurd.
Then the worse scenario happens: People use Redux, not knowing what problem it is supposed to solve, and tweak/modify it or do things in a way that kills the point: they don’t get the benefits of the centralized state and low code abstraction because they piled on countless of connect hacks, middlewares and classes on top.
So they get all (most) of the boilerplate, and none of the benefits. That’s terrible.
But it’s still worth keeping in mind that there IS a problem with sprinkling state all over a frontend app. It doesn’t matter for tiny apps, but for large ones, it does. And embracing Redux and the FP principles it enables is one way of solving it.
I totally agree people shouldn’t start with Redux without understanding what its for…but if they go the “pure React, local state” way and build a significant app around it, they also should take care to understand why many people rejected that approach to begin with, long before Redux or Flux even existed.