The "why immutable" question usually attracts zealots that throw around terms like "easy to reason about" and detractors that mention "slows code down and is harder to write"--as if those statements were inherently true, universally understood, and defined in an agreed-upon way. None of those are the case.
The usual argument in favor of immutability is not that mutability is a big problem in general, but that when unexpected mutation occurs, it's a really hard to find (debug) type of problem.
If you have a well behaved codebase that does "a = { :foo => 'bar' }; render_hash_to_browser(a); store_hash_to_database(a);", you're fine: you can assume the same data ends up in the browser and in the database.
However, if that assumption ever fails ("users are seeing data that isn't in the database!") it's often a debugging nightmare, because you have to dig down into any code that might possibly ever touch the hash to see if it's accidentally mutating it. This includes utility functions, totally unrelated areas, et cetera.
If you have a good debugger to assist you, and an easy way to attach your code to a harness that follows bug-reproducing paths, you're set. But those things are a) never as present as we want them to be ("just don't write bugs, duh!") and b) tend to be harder to get working in old, large, monolithic projects--just the kind of projects where sneaky mutation can become a frequent issue.
Now, all debugging is hard. And a lot of it involves delving into code you've never seen/touched before to find a bug. But sneaky-mutability issues typically expose a much wider variety and volume of code as suspect. Because of that, mutability issues often tend to be, if not objectively more difficult, at least objectively more frustrating to debug.
With this as in all things, there's a spectrum. Some folks are fine with ultra-dynamic languages that let you mutate/bind anything, and protect against that with convention and tooling. Hell, some folks are fine with languages that mutate their data structures when you do nothing but read from them (https://perlmaven.com/autovivification). For others, they just want control over what you can bind to names (a type system, or "const"--the Java/etc kind--which prevents rebinding). Still more folks want the ability to opt into truly immutable deep data structures. And others want everything in their platform to be immutable when they use it, and have all the mutability (which you nearly always need, if only for performance alone) handled behind the abstractions of their runtime.
However, past a certain criticality or size (of code/complexity/age/number of developers threshold) of a project, it often becomes necessary to move "up" that ladder to something that provides more programmatic/automatic assurances about "what is happening to my data as it passes through all this code?"