Personally, I don't think we would benefit much from 'flux-like' libraries if we don't fully understand what Flux, and specifically its dispatcher, is doing.
Taking Reflux as an example, the biggest difference between this library and Flux is that Reflux has no centralized dispatcher. Facebook’s developers (the creators of Flux) commented on this topic, by saying that not having a proper dispatcher may prevent your application from scaling well, and I do agree with that.
Flux is a very elegant solution to a well known data flow problem. If you've ever been on a situation where it seemed like data wasn't loading, or one component wasn't talking to another component, those problems are largely reduced (if not completely eliminated) if you do Flux properly and maintain the uni-directional flow that it promotes.
We should learn what pure Flux has to offer before trying to replace it with a different implementation of the original pattern. Yes, pure Flux may make you write a little extra code (i.e: that switch statement within the data stores), but if it has been working and scaling well for Facebook then why trying to replace it?
If you find that it is absolutely necessary to use a different Flux implementation, I would strongly recommend to look at those ones that stay very close to the original Flux pattern. Fluxxor is a good example. However, I would be hesitant of using a library that has not been tested in well known large scale applications.