I agree that for most users Redux feels like a lot of boilerplate. At the same time I think most people underestimate were we came from. Personally I wrote a huge amount of Angular code before and at a certain point I felt very unhappy about the two-way data binding and state handling in Angular. It was unpredictable in a huge code base at some point. Then it was the time of Flux and in our company we introduced a stores and unidirectional data flow implementation of our own. Afterwards Redux got announced and we loved the clear constraints and lightweight API from the beginning. We use it now.
In a team of developers everyone can clearly follow state changes, the state itself and the places from where the state changes were triggered. Redux is scaleable and shouldn't be used for every small project which could live without a state management library and should use setState instead. Redux simply works, even though you have already a big amount of actions in production.
I think MobX is on the right path to give an alternative way for state management. For now I see a clear benefit to kick off smaller projects in smaller teams which don't rely on Redux' constraints and scaleability. Little feature op-tins like useStrict will help MobX to have a more scalable state management system. Otherwise in a growing code base it will feel like the old Angular days with two-way data binding. In the end that is the power of MobX, because it isn't opinionated: You can either mutate your state directly in a component or build a proper infrastructure around it to make it scale.