As a back end developer, Redux had instant appeal to me, because I've written apps that managed state by generating events asynchronously, serializing them, and using each one to update state in turn, generating a series of discrete state snapshots that were used to serve read operations. In doing so I reinvented Flux without realizing it (as everybody does when they structure an application that way.) When I encountered Redux, its concepts mapped exactly onto the concepts I already knew, so it was easy to get started. I had written reducers before, though I didn't call them that. After previous brushes with front-end development, I was excited to have a clean conceptual separation between state management and rendering the DOM. Managing that relationship seemed to be a place where even expert front-end developers got lost, so I was happy to have a radically simple solution.

I can see why the Flux concept would seem arbitrary and overengineered if you hadn't been forced to solve that particular problem before. For me, the baffling parts of Redux were the ones that were specific to React, because my understanding of React was very shallow. The amount of React I had to learn to understand React/Redux felt like way more than I would have needed to learn to write an app without Redux. But for me, it was worth the effort to be able to use Redux for state management.