For my purposes this optimizes at least as well as ImmutableJS, and there is no overhead from loading and using a dedicated library. However it does require extra boilerplate and manual updates to version tags each time something changes, and it can cause confusion if you forget to update a version tag or accidentally update the wrong one. Anyway, it is one alternative, but if you don't have a compelling reason not to use ImmutableJS for optimization I'd probably go with that. Of course it is perfect for undo/redo functionality too if that is a requirement.
The undo / redo gains of ImmutableJS quickly vanish when you're working with remote data and the leaked getters aren't fun. A little UUID juggling is worth it if it allows my components/reducers to work with plain old javascript objects and still get fast shouldComponentUpdates.
http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-pr...
One of these days I'll put up another piece on Flux/React, and an example application to demonstrate an approach that doesn't have a lot of dependencies (not even ES6, for example).
Also I have not run into any pitfalls using ImmutableJS yet apart from the extra overhead, so thanks for the heads up.
With immutable state you can do an identity check on the current state node (pretty much free), and only perform the render if it fails. On specific components you may want to go further and do a deeper equality check if the identity check fails (if rendering is expensive) but immutable collections generally give a lot of bang for your buck when it comes to skipping state -> vdom.