Before Redux was probably even an idea, when Flux was reasonably new, my boss at the time basically said this new Flux thing looked like what we needed for a project and told me to learn about what made Flux tick and start building the project on that pattern.
I dug around, I looked at Facebook's documentation and propaganda for the pattern, and I came to the conclusion that Facebook people didn't know how MVC worked and decided to invent their own thing as a replacement. Then, I started building something, and realized that Facebook's Flux dispatcher library was getting in the way.
I built my own from scratch, and suddenly I understood the elegance of the pattern. It was not at all what Facebook's marketing about it said. It was not an MVC replacement at all. It was something else entirely, and should never be treated as an MVC replacement. The explanations about how it solved problems with MVC were nonsense: it was just a different pattern, for wildly different use cases, and the MVC-replacement propaganda I read still made it seem like people at Facebook just didn't understand how to use MVC.
My dispatcher was lightweight and clean. It was one of the nicer bits of code I've written, and I'm still quite proud of it, years after leaving that job.
I was the principal dev on that project. After a couple of weeks of building a complete application with a deceptively simple architecture that did all the heavy lifting with ease, I took a day off.
It was one day. It was a Friday, which meant that for the people there a quarter of the day was taken up with meetings. Somehow, in the midst of this, disaster struck.
When I came back on Monday, I discovered that the boss and a co-worker had decided they would just replace all the guts of the application with a pile of libraries designed for MVC, but bend them into a Flux shape, kinda, sorta. The result was slower to build (q.v. JavaScript "build" crapola), slower to deploy, slower to test, and slower to operate. It was slower to debug, slower to extend, and generally miserable. It required fixing or changing something in the plumbing almost every time a feature had to get added. My work on a small, beautiful, efficient architecture was destroyed, and nothing we ever did with that application ever actually required any of what they did to it.
They told me I hadn't documented how to use the architecture in place well enough, so they had to rewrite it to get anything done, but the result was half-broken, and I had to finish what they started to be able to continue myself on Monday, and they never actually did anything with what they created that justified that claim.
A couple months later, I learned they hadn't actually looked at the documentation I wrote at all. They just decided that my bespoke implementation must be wrong because I didn't use existing tools. Well, shit, I didn't need existing tools. The whole dispatcher was something like twenty lines of code. The rest of the basic structure was in parts even smaller than that. The "rewrite" of the system was probably a thousand lines of library code (I'm guessing; I didn't count) and close to two hundred lines of junk around them to make things fit together, all so we could write a bunch of boilerplate for every single thing we wanted to do thereafter.
(Note that my references to all this code excludes the React tools themselves, installed directly from npm because yarn wasn't available yet.)
long story short:
I think I understand what you mean about a pattern, as opposed to a framework or toolset. Also, even if the origins of Flux (and, thus, ultimately of Redux) were in some Facebookers possibly grossly misunderstanding how to apply the MVC pattern, Flux as a pattern was an excellent approach to addressing some specific needs for application architecture.