In short, both xes in your example are different variables.

It is more like:

x@1 = 1
x@2 = 2
IO.puts(x@2)

(It will look almost exactly like that in Erlang code)

The whole pattern is called rebinding and Rust offers something similar (if that make it clearer):

let x = 1;
let x = 2;
println!("{}", x);

Just in case of Elixir you do not need the let prefix.

To show that more explicitly in Elixir you can do:

x = 1
fun = fn -> x end
x = 2

IO.inspect(x, label: :x) # => 2
IO.inspect(fun.(), label: :fun) # => 1

I’d explain (the benefits of) immutability differently:

let array = [1, 2, 3];
let reversed = array.reverse();

In JS you cannot know just from reading that piece of code if array is now equal to reversed or still the original value assigned in the first line. You’d need to familiarize yourself with the implementation of Array.prototype.reverse(). In this case reversed === array, but code like that causes/caused enough problems that there’s also a Array.prototype.toReversed() nowadays, which returns a new array instead of modifying the existing one.

In elixir you can have:

list = [1, 2, 3]
reversed = Enum.reverse(list)

No matter how Enum.reverse/1 happens to be implemented it cannot make the list variable resolve to any value other than [1, 2, 3]. Essentially immutability is equal to having pass by value everywhere and no pass by reference. That’s the model upheld by the VM.

Immutability is independent from assignments – the act of creating the relationship between variable and the value it represents. Immutability only means your values (in memory) will never be modified. It doesn not mean that the variable x will always represent the same value. Once you changed what x points to there’s no way to get the value it pointed to before (even when it might still exist in memory).