Building any program is often an exercise in modeling and managing complex state. While object-oriented programming can make it easier to model this state, it can often give rise to problems of data synchronization and consistency. If the models representing state can be changed at any given time, then it becomes more difficult to reason about the current state of a given application. It becomes difficult to understand when and where state is being manipulated, or even how best to modify state.
This is why the immutable nature of variables and state within functional code is so appealing. If the models representing our state are immutable, then the contract with which to create or modify state becomes much more explicit. To represent a new state, we must create a new model to hold that state. This becomes easier to trace as we can now rely on the static, unchanging state of any given variable.
This becomes even more relevant when paired with the next useful property of functional programming: limited side effects.