> Container/Component

That's not part of Redux, it's a separate design pattern you can use with any Flux architecture. React-Redux doesn't even require you to do it that way, and for good reason: you might not need it. There's nothing wrong with just importing a store reference wherever you want it. That's a totally reasonable pattern for some applications.

This illustrates my point I guess. There's so many people thinking about how to architect and implement React applications that there's a lot of cargo-culting.

I disagree that its "literally" the same. Vuex requires you to mutate state, through their API (if declaring new/dynamic properties). Redux is agnostic about how you handle state, but encourages immutability. Vuex is inherently not immutable, its coupled to the vue reactivity system which is based on mutations & memoization.

Vuex & Vue are the easier APIs to learn. Not only that the developer ergonomics are just better for Vue's API. For example in vue you have "mounted()" instead of "componentDidMount()" or "ngOnInit()". Likewise, redux requires learning CS terms (if you don't know them) like thunk, saga, memoized selectors, etc. Vue uses more layman's terms, like "computed" instead of "memoized selector" which just makes it easier to learn.

My big hangup with Vue is having to declare reactive properties up front. It's author says this is a best practice anyways, but it leads to hard to debug issues when you accidentally declare new properties at runtime & you get race conditions. With react & redux both making immutability possible & encouraging immutability, you get easier to debug apps. But there is a more up front investment.

I also really love Vue's single file components. I know you can do that in Angular & React, but again the API is just so much more ergonomic in Vue.

It looks like VueX supports async out of the box. That's a huge win IMO.