The problem is I always end up writing a state container that's similar to redux at some point if I don't use it. For simple things, you don't need a state container, but where is the line between simple and complex? It's hard to tell, and since redux is so low overhead, why not err on the side of using it now if you think there's a chance you'll want to later?
The key here is end up if you project too much into the future then it is premature optimization. I might end up becoming the next Google let's write our back-end in C++.
Have a go with VueJS - it's even nicer than React, kind of elegant, surprising though it is to include that word in the same sentence with Javascript :)
Redux (and every design pattern) is something most ppl don't need, but they apply mindlessly. At least Redux abstracts the application logic into a central state and thus makes it easier to replace Angular in favor of React or Vue.
True, mindlessly applying patterns is silly, but not applying any design pattern means you will have a random software design (aka. spaghetti code) which is way worse.
Funny, I started writing a blog post about this very subject today.
I think the common problem with people selecting poor patterns for a given context, is they don't pay attention to the context. It's more 'I got this pattern, lets use it' rather than 'I have a whole toolkit, and I can identify exactly where each one need to be used'. It's such a problem I even came up with a term to define that specific anti-pattern, 'MissingContext'.
Even as complex as my application goes ... simple local instance variable as state still works fine most of the time. In fact i find passing in callbacks works fine for most web apps i dare to say unless maybe when you're writing some sort of editors for the browsers.
I come from Object-oriented background therefore i find the Redux-way (functional programming) hideous.