I'll take this as an opportune time to link to two very helpful and useful posts about Redux from its author (Dan Abramov) about upsides (http://stackoverflow.com/questions/32461229/why-use-redux-ov...) and downsides (http://stackoverflow.com/questions/32021763/what-could-be-th...) of using Redux.
Namely, I see Redux offering a nice advantage over flux in encouraging reducer composition (and functional purity) for modularity. "This pattern also enables wonderful features like no-user-code undo/redo. Can you imagine plugging Undo/Redo into a Flux app being two lines of code? Hardly. With Redux, it is—again, thanks to reducer composition pattern. I need to highlight there's nothing new about it—this is the pattern pioneered and described in detail in Elm Architecture which was itself influenced by Flux."
In short, the key value add for Redux, is not necessarily that it's (overly/inadequately) decoupled, but that it is necessarily forcing a decoupling via functional purity for the /purpose/ of modularity. That is, it is taking a more functional approach to state management for React components, favoring the event log paradigm rather than black box paradigm. This brings with it the ability to be "designed with use cases such as logging, support for Promises, Observables, routing, immutability dev checks, persistence, etc, in mind." Of course, these aren't impossible with Flux, but these things follow intrinsically from Redux.
Take my opinion with a grain of salt because I'm not super experienced with Redux yet, but I really like what I've seen so far playing with it.