Honest question: is immutability complicated in Clojure because it's hard, or because it's running in a virtual machine with no meaningful support for it?
The Erlang VM has immutability deeply baked in, and it just works(™).
Erlang is typically used for problem domains (eg. fault-tolerant servers, network brokers & routers, message queues) where immutability fits the problem domain pretty well. If you want fault tolerance, you typically need to store all your state externally anyway so you can replicate it, and make all your logic stateless so you can restart & re-run it if a node fails.
There are some problem domains - eg. GUI software, web browsers, simulations, many of the more complicated parsing, data extraction, or graph-traversal algorithms - that are inherently mutable, and Erlang is not used very much in these domains. C++ still rules the roost there, even though many of its practitioners hate its shortcomings.
I would argue the immutability is actually not a great thing in Erlang to be honest. It makes it hard to reason about what gets copied, what gets shared in the global heap which may be a source of contention, makes code unnecessarily verbose, etc. I think it's one of those features (like lazy evaluation in Haskell) that language practitioners tend to advocate without necessarily understanding what tradeoffs they are making in the process.
Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.
There are some problem domains - eg. GUI software, web browsers, simulations, many of the more complicated parsing, data extraction, or graph-traversal algorithms - that are inherently mutable, and Erlang is not used very much in these domains. C++ still rules the roost there, even though many of its practitioners hate its shortcomings.