For example, since Redux is a monolothic store of application state, could the state tree get too big?
Any time the user interacts with the data on one line (among hundreds or thousands) calculations are redone at four different levels so we don't have to keep going back to the back-end to update the data, instead we can keep working with the data we already have.
So... With all that said, how did it work with Redux. Eh. Not so bad. I don't love it the way I loved AngularJS after I used it for the first time, but it's OK. The results are complicated but given how we're using it and what we're doing, I don't know how it wouldn't be complicated. I dislike that there's going to be a significant learning curve for anyone who encounters this page in the future, but the previous version of the page was a total trainwreck. At least this time I can do a lot of stuff and envision changes to the calculations and how it all updates and I don't break out in a sweat.
The biggest area I ran into problems was that a lot of the data we need to keep up-to-date is derived data (for example, an array of data for Angular UI Grid which has to use a heavily modified version of data in the state). Redux doesn't really do anything to help you update that as needed.
There are a lot of reasons there are so many plugins and add-ons for Redux, I think you might find it interesting to go over those so you can learn some of the themes they have and see what problems they try to solve. Actually, I think that's a worthwhile thing to do with any new technology. Go look at all the software which has sprung up to fill in the holes and you'll learn a lot.
There may be a general solution for this out there, or at least an approach that makes it workable for some cases, but I haven't come across it yet. And of course it really depends on how demanding your performance needs are. You might be able to get away with using Redux for animations despite the above.
It would be great to see something like Redux that gives you debugging precision all the way down to the animation frame, but which avoids the garbage problem.
Maybe your application is simpler to model as a mutable assembly of little pieces, where the protocols between those pieces are more important than managing their arrangement. (Maybe like in a modular synth?)
Maybe an existing team or project already has a good thing going without using Flux.
However, all of these are pretty thin and narrow. Getting rigorous control of the state of your program is actually super useful, as is treating events like immutable facts that build upon each other.
In contrast an MVC application encourages modulization of discrete components of an app. Which could lead to situations in which state could be duplicated. To get around this, singletons can be used to avoid duplication. This involves a central store. Much like a single state tree.