Very cool! I think this is a valid demonstration of an approach that can work. I definitely agree that too many times beginners are directed as though they must use Redux and other technologies with React when it is not absolutely required.
At the same time, if you are seeking an architecture that keeps UI components as "dumb" as possible (in that they don't care about the data... they just render whatever they are told to render), then using context (or using props by passing things down through the tree) can couple your data to your UI too closely.
I have found that separating your data layer (read: business logic) from the UI is beneficial because it allows the same logic to be used with many different UIs. Thinking about using ReactDOM and React Native for iOS and Android: using Redux allows for the data layer to be structured in a way that various UI layers could use the same business logic (and thereby the same API), while the UI for a given platform is uniquely tailored to the usage expectations on that platform.
Going even further, since this is all just JS it is possible to package the business logic (which, in the way I've been referring to things would be the Redux bits) into one npm module (using a private npm registry) and shared in multiple places.
This would allow for there to be a Web version, an iOS version, and an Android version -- all of which use the same data layer module, but with UIs that account for the different types of users on each application.
Example: a complex web-app that is scaled down to only a few features on mobile - the UIs can differ, but if the data layer is consistent, then developers only change that layer when it is needed and the various UIs just need to consume the new version of the package. The downside to this is a breaking API change will necessitate many changes (potentially), but we're all used to that with modules anyway when those types of changes happen.
Just some thoughts! Awesome demonstration!