Let’s try to unpick this argument.
First, let’s see a javascript example of mutability:
a = {}
// b holds a reference to the same data as a
b = a
// mutability: we're changing the data
a.x = 1
// data pointed to by b is implicitly changed
console.log(b) // {x: 1}
Now let’s see a javascript example of rebinding:
a = {}
b = a
// rebinding: a points to different data
a = {x: 1}
// rebinding a didn't change anything in b, hence it's not mutability
console.log(b) // {}
The former (mutability) is problematic because it’s much harder to reason about the code. For example if we invoke foo(a), we have no way of knowing if this will change something in a. We need to read the code of foo and all the code it invokes (recursively!) to reliably answer that. This is extremely tedious, prone to errors, and whatever assumptions we have about the code today can implicitly change tomorrow without us knowing it, for example if a team member changes some indirect dependency of foo.
The latter (variable rebinding) doesn’t suffer from such problems, because rebinding doesn’t change the data.
