> So behind the scenes, every one of those statements will make a whole new user object with a whole new address object so that it remains immutable?

Not a "whole new" one since it will use shared references to the parts that didn't change (which is valid since they're immutable). And in principle the VM could even recognise that the new object is replacing the old one so it can be edited in place.

> Still, what happens if you do that with a big object graph?

I've literally never seen it cause a real-world performance problem, even if it theoretically could.

> Also, the original strong need for immutable data in the first place is safety under concurrency and parallelism?

Partly that, but honestly mostly development sanity and maintainability. You can iterate a lot faster on immutable-first codebases, because it takes much less test coverage etc. to have the same level of confidence in your code.