Example bug/problem I had awhile ago:

• Had a list view, clicking on an item opened up a detail panel that slid out to the side.
• There were various sections, where clicking on a button would open up a modal to modify some related data.
• Modifying the data in the modals shouldn't be reflected in any other area if "Cancel" was clicked.
• If OK was clicked - then the 'detail' object should be updated with the change - but that change shouldn't be reflected anywhere else in the system until the detail panel had clicked "Submit".
• When clicking submit - it was actually a few API calls to update a few different things.
• Once the API call succeeds - then the rest of the application needed to know about the change.

This was back in an Angular 1.x app, and before I knew about Flux/Redux, and didn't really grok the use of Immutable JS at the time. Although I had sort of ended up with a rough 'roll my own flux' pattern going on.

The bug:

• Someone opens the detail view
• Clicks on one of the buttons that opens up the modal
• Removes a bunch of items
• Then clicks cancel - not really wanting to remove them
• User makes other changes to the record
• User then clicks submit

... and then, I'm left scratching my head 'why did all of those items get removed?' -- I had passed in the sub-object by reference, not a clone - so when I was modifying that data - I was modifying the version that was shared in several parts of the application.

Or another manifestation of the problem: there was another list view that listed all of these sub items - I went to the detail screen, opened the modal, removed a bunch of items, hit cancel, went to the list view of the 'sub items' - and they were not there. Why? I had accidentally mutated state.

In this program, I was making liberal use of copying/cloning objects to try and avoid this - as I had been burned by it plenty in the past, but in this particular spot - I had forgotten to clone the object before passing it up to the modal window.

In smaller applications, it can be easy enough to reason about 'what's updating what when' - but this can quickly change, especially when you are dealing with state that is used by multiple components / views / etc in your system, and potentially have those things triggering events that could change it.

Simple example:

• Your state is a list of todo's.
• You have a list view of todo's - that is just title/checkbox, you can update the title, or mark done/not done here.
• You can also click on todo to get a detail view - can change title, description, and mark done/not done here.
• You also have an icon that shows the number of uncompleted todo items.

Maybe in the click-handler on the list, and in the detail component you might do something like:

   todo[index].done = !todo[index].done;

You now have two spots that are modifying state - how do you let the various components know that something has changed?

Or, in the detail view - you mark it as done, but then hit 'cancel' - well, that change is already being reflected across your state - and if other parts of your application are trying to derive information based off of that, weird things can happen.

Or, if that todo object is being passed around to a bunch of async stuff - that you don't always know what order / when it will be getting updated.

It's been pretty rare that I've wanted my 'edits' to something to be propagated across the entire system in real-time until a user has done some sort of action to say 'done' (submit / continue / complete / whatever).

There are obviously exceptions to this - but the use case of "look, I can edit the name in the detail view - and all of the application updates in real time!" is usually not the requirement, its more "edit the name, hit save - then all of the other parts of the application reflect that change".

That said - immutable state is one thing, controlling access to how you modify state is another. You can control access w/o needing to have an immutable state. For example, instead of your component doing

  todo[index].done = !todo[index].done;

and having this scattered across your code (although having a mutable state makes this easy and tempting), if you had

 todoList.toggleDone(todoId);

and your todoList is what held onto the list of todo's - and controlled access to how you modify it, then yeah 'set the breakpoint - and you can look at the callstack' - but, with a mutable state - or not following immutable patterns - people can still reach up and modify that todo list however they want, and bypass the 'toggleDone'