In fact, he expands on closures in an earlier post (about Elixir):
Proper closures should only contain pointers into immutable data (which is the case in Erlang) - no pointers into mutable data. If a closure contains a pointer into mutable data and you change the data later you break the closure. This means you can’t parallelize your program and even sequential code can contain weird errors.
That's just wrong, in most cases. Mutable closures are incredibly useful. Erlang, however doesn't actually need them, because where I (a scheme programmer) would use a closure with mutable state, Erlang programmers would use a process running a function that takes that state as an argument and runs forever, tail-calling itself to change the state. In most languages this is impractical, because most languages don't have erlang's threading semantics.
They are, however, incredibly useful in Erlang. Most languages don't ~need~ closures. The whole point is that they're useful, though.
Haskell doesn't have mutable state; it still has closures.
Mutable or immutable is somewhat orthogonal; I admit, coming from Erlang to Javascript I was -shocked- and very facepalmy when I learned that closures close over variables that can still vary. That is, I couldn't just pass back a function and expect it to behave the same way depending when I called it. I had to add an additional scope in place and bind the values anew (i.e., a new function, passing the values being closed over into it as params). Immutable is much easier to reason about, much easier to write with, and despite being more limited in what you can do with them, I'd argue just as useful. Everything it prevents you from doing there is some other, safe way of achieving; the same as comparing mutable vs immutable in other contexts.
They don't do it differently, they simply avoid the question by not letting you change any binding ever. In languages that embrace immutable bindings but don't enforce them, like scheme, closures work exactly as the parent describes.
Languages with immutable bindings (the author is one of the original designers and implementers of Erlang)