For example, say you have an action that fetches a bunch of blog posts, then refetches later. If all the items are identical since the last fetch, you want to avoid rendering. So that means that whenever you deal with data updates, de-duplication has to occur at some point, preferably early on in the data layer when the surface area is minimal.
That de-duplication would need to "intern" data; i.e. if you fetch the new blog posts, check each of them if they are exactly the same as what's already cached (time stamps or version numbers could be used to save deep equality checks), and keep the existing object if that's the case.
Of course, you will still end up with lots of identical objects (different identity, but same content) purely because mutations generate them. For example, a user goes to a text field, types a character and then hits backspace. Now you've produced three different objects: version 0 (original data), version 1 (character added), version 2 (identical to v0, different identity). This will correctly re-render each version, of course. But let's say you had some other component (like a preview) that only updated every second. It would receive v0, v1, v2; at this point the delta of v2-v0 is zero, and there's no need to re-render; but a shallow equality check would cause it to. So de-duping needs to be built into all sorts of places you might not anticipate.
There's a few different reasons why handling data immutably in a React app is a good thing. The main one is that it allows straightforward implementation of `shouldComponentUpdate` by simply doing shallow equality checks against props and state to see if anything has changed. (I wrote a Reddit comment yesterday explaining why that works well, at https://www.reddit.com/r/reactjs/comments/666uin/can_someone... ).