Redux creates a lot of indirection, and itself can have odd side effects. Like I have a Componet that is a grid, and you can select an item in the grid. This selected index is held in a Redux store. Now, when the user clicks to edit a different grid object, the system uses the same grid. Because Redux is decoupled, the selected index is unchanged, and when the new grid is rendered, it renders with the old grid item selection.
This isn't terrible, but if I had used local state, then all I would have to do is reset the key on the grid editor instance, and the state would be reset. If I use Redux, I have to use lifecycle methods to reset the essentially global state variables (Redux is basically an interface to a global object store).
I used to use Redux to store all my data. But if I use Meteor data connectors (or Apollo), then they have already implemented various subscription optimizations to unsubscribe from data sources, and clean up member a bit (presumably). If I put everything in my Redux store I have to manage all that manually. This has pros and cons.
I may yet go back to Redux and use some of those fancy offline libs, but I'm really on the fence about it. The redirection in Redux does cause some headaches. I can still get unidirectional data flow with Meteor's connectors, and it actually feels cleaner that way, easier even to reason about. Maybe it's just me though.