Programs that use mutability are easier to write, up to a certain level of complexity. You have an object that contains a value that's almost what you need, so you mutate the object and you move on.
But programmers spend a lot more time reading code than writing code. And reading code is harder than writing code. Reading code with mutable state is a lot harder than reading code without mutable state. If the language guarantees that no state is mutable, it's a huge cognitive win.
One thing that makes mutability especially painful is concurrency. When multiple threads can access the same memory, you risk a race condition each time the program reads or writes an object with mutable state. This makes even very simple reasoning about programs hard. Simple-looking code like
# x : integer
assert (x + x) mod 2 == 0
may be wrong if x is actually mutable by another thread.
This concern can be alleviated by making the language fully immutable. But outside of some special-purpose languages, programs have to deal with the mutability of the world around them — they have to handle input-ouput. So good languages make mutability explicit. For example, in Haskell, all mutability has to be handled through monad operations. In Rust, the type system keeps track of which objects are mutable and of which objects are potentially shared: the world is immutable by default. In Erlang, all local computation is immutable, except for interprocess communication and direct access to a single, compound mutable object (the process state).