It does not give you more from that list. MobX is, by design, non-prescriptive about who's touching your stores, how they're being passed around, how they're being updated, or how the API of your store looks. It's all fine if you have one or two developers but is a dangerous thing for large teams.
Have you used Redux's devtools? I wouldn't give those up for anything. Not sure if MobX has anything comparable.
I have used them, yeah. Mobx-state-tree (MST) can be wired directly to the redux dectools.
The strict mode in mobx ensures that stores can only be updated via actions, so you can restrict updates from that point of view.
On the flip side - mobx makes it dead easy to minimise your core state and transform it efficiently (and declaratively) for use in the front end (or wherever). I'm told reselect helps that use case now, but you'd be hard pressed to do a better job than mobx in that regard.
Personally, I found that my code was too obscure with redux. In implementing our login flow (it has more paths than most), I found that it was hard to see the real code between the architecture.
As ever, it's important to evaluate these tools critically to see where the fall down (which is what I've been doing with MST today). Too often people evangelise their product of choice while hiding the areas in which it's weak.
And to play devils advocate, redux will have you push a lot of code into middleware where people are left to do all sorts of crazy - it's not all the rosy enlightened path :-)
One of the things that pulled me to MST was that I couldn't see a simple way of managing cross-cutting concerns with my mobx architecture. MST (and redux) make that dead simple.
Have you used Redux's devtools? I wouldn't give those up for anything. Not sure if MobX has anything comparable.