That's a good approach, seriously. You don't need redux at that point; don't use it. I'm not even suggesting such applications are 'trivial'; they probably just don't have excessively complex component hierarchies and interactions.
...but please read this really quite old article if you haven't before: http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/
This is an argument that has literally been made a hundred or more times before, and nothing has changed about it.
Sure, this article is about dependency injection, but its essentially the same domain. You can argue that manually passing props is the same of 'poor mans' dependency injection, and it certainly has value in that there's 'no magic' in it.
...and certainly, you fall into the pit of pointlessness and frustrations when you use magic, but there's no convention to make the magic 'all work without surprises'; but the same issues still apply.
Once the application reaches a certain size, the maintenance burden of the 'simple' approach becomes prohibitive.
/shrug
A lot of these solutions, like static typing in non-performance areas, and so on, are about "how do we get this new engineer to start working on code that he has no idea about quickly". This problem only exists in large organisations and I personally don't think large organisations are very good at anything so don't care about those set of problems.
Basically it comes across as another "how do we hire large numbers of average programmers" problem and the facebook talk said exactly that. State managers, like dependency injection, just add another level of indirection that make your application harder to debug. You can no longer just follow a simple chain of methods, because everything disappears into the magic land of the state manager as soon as you start using (as the vuex example) store.commit("increment", 10); instead of actual methods and so on.
If you still don't see any value in these tools, don't use them.
All I'll say is this:
In my experience, people tend to consider their applications to be simple enough that a simple solution is sufficient.
However, in reality, that seldom seems to be the case.
UI is hard to get right, and has a tendency to drift towards complexity over time as more features are added: I can think of several people who have picked the naive simple solution and regretted it later; to the point of rewrite in some cases.
People who picked the complicated solution sometimes regretted the extra burden of complexity, but I don't think I've ever seen this as a cause for large scale failure or rewrite.
the order of the modifications
who performed them
how they modified them
So the state manager adds that in as well. You can add getters and setters and enforce synchronous programming in certain methods, but then you are 90% towards a state manager.
I honestly think its not that bad. Elm essentially does that, and its arguably more productive than React's ecosystem.
You might just want to optimize things a bit by making non-leaf components take a simple "model" prop (that contains all the properties they need) to reduce friction a little, but aside for that it might even make code better by forcing a more thoughtful component hierarchy.
After all, if component A renders component B, then A really DOES depend on B's props. Magically having B kinds of hide dependencies.
After all, short of using DI containers, if I have a function that calls another function that calls yet another, I DO pass arguments all the way down. And React components are semantically just functions.