I've noticed that when programmers are introduced to a new technique there is a tendency to apply it everywhere. I had this experience when first learning recursion, it was all I used for a while, until I realized that was silly and now only use it where appropriate. This is true for OOP, functional programming, strictly adhering to even esoteric details of REST, etc.
I've found programming to be a lot like cooking. I really liked garlic, so when I first started cooking I would routinely add a couple extra cloves, until I discovered there very much was the possibility of too much garlic. This is true for each ingredient, you try stuff out and as your experience as a chef grows, you start to be able to suss out the right amount of each ingredient added at the right time.
Programmers are essentially virtual craftsmen, you have a set of tools and you try to build something effective with the tools you have. If you adhere to a principle so fiercely, the pieces of the puzzle often don't quite fit. You end up with a circle or square where something more acorn shaped would be most appropriate.
Anyhoo, don't take my word for it: "A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson or "Only a Sith deals in absolutes" - Obi-wan.
The Redux FAQ addresses this at http://redux.js.org/docs/faq/OrganizingState.html#organizing... . Note that a number of the linked comments regarding whether or not to use Redux come straight from Dan Abramov himself.
Also, I have a number of articles on React state management practices as part of my React/Redux links list, at https://github.com/markerikson/react-redux-links/blob/master... , which may help clarify some of the ideas as well.