That said, my personal opinion: the deeper you get into a big project the more you'll see the incredible value of the approach. The breakeven between the overhead of learning the approach vs the productivity (and performance improvement) of using it comes pretty early on, in my opinion.
With a lot of software, the more I get deeply into a project the more I feel I'm battling the artificial constraints of the tools I'm using. Flux is exactly the opposite. The deeper I get in, the more I feel it's working for me (and I'm not even using their dispatcher - since I had written my own initially before flux came out, so I can't speak directly to their dispatcher, just the Flux design styling within a React project).
It's very small and removes boilerplate, but still isomorphic.
You end up building a ton of boilerplate code that is capable of handling anything your system evolves into, but most of it is wasted because each part of the system typically only uses a small subset of functionality of the framework. So you're left with a bunch of big crufty systems laying around. When I want to be the most lightweight and agile and capable of changing my direction is at the beginning of a project when I'm still learning how the system will work. These frameworks make it really tough (at least for me) to do that so I end up not using them.