IMO advantage is the predictability of state over multitudes of ui changes. Everything that changes in app (data/ui state) is contained in a single object called the state.
I don't Redux. But compared with Flux, it's much better designed. Flux is more like Backbone models but simplified for React. It's a collection of several data sources with event emitters, which is still a bit tedious for React apps.
Redux is embracing single store and immutable data structures, and it fits unidirectional data flow better. Some people may be amazed by it's time travelling debugger. Redux is a rethink of stores, and the idea is shiny. Also Redux borrowed some ideas from Om like cursors to make nesting components fetching data easier.
The thing I hate Redux is the core idea of it is totally from Elm. In Elm the ideas are simple and beautify while it turned out to be complicated in Redux with high order functions with many hidden states or side effects.
Ryan Collins
I’m a software engineer working on the web, specializing in React & GraphQL. Avid functional programmer and aspiring data scientist
Redux has been agreed upon across the board as the Flux implementation. Flux is a great idea, but it left a lot of questions that individual developers attempted to answer with their various libraries / implementations. In its current iteration, Redux implements what many consider to be the most important parts of Flux (uni-directional data flow) without making use of the unnecessary parts of Flux (the dispatcher for instance).
If you are interested in hearing a more eloquent description of the differences from the creators of Redux and Flummox, listen to this Javascript Jabber episode.