Earlier quoted context omitted.
Right that's one object. Often you need to change the state of a bunch of related objects in a transactional way. The way redux works for example. It's somewhat analogous to database transactions.
I’m not a functional programmer by trade, but I think you’re alluding to (and should reframe your argument to discuss) concurrent reads and the implications of immutable data in a multithreaded scenario. It’s about simplifying your programs state machine. If I have some object A in an OO world, some N threads may act on said object concurrently resulting in some degree of non-determinism for any function of A. In FP,…
And so on and on. All kinds of objects need updates for their states. You need to direct all this stuff, without forgetting things. Otherwise the state of your objects will become inconsistent and at some point it will show as some kind of bug. At that point you might find yourself debugging the whole thing, to find out when the inconsistency starts or what causes it.
No need for multiple threads or any of the kind. Complications from splitting the state up and parking it in various objects and having to tell the computer how to update these objects. Instead of looking at 1 function at a time, which only works on its inputs and gives an output, you have to remember to call all the appropriate methods across some reasonable part of your entity landscape.