You don't have to copy the data; it is immutable. Why copy something that isn't going to change? Are we being charged for empty RAM? Different objects can share the same structure. Famously, this is what Clojure does. Theoretically it can be faster than mutating objects because you only have to write the parts that are changing (which is the same as a mutable object), you lose something to overheads (might be nearly negligible) and have enormous gains in situations where you might need a copy of an object for some reason because that is free; there isn't any reason to actually do a copy unless the data itself is going to be mutated.
Concurrency + statefulness means you can't have mutability because then you would run the risk of a concurrent update overwriting another. But you can have concurrent read-only state, so long as concurrent writing is not permitted. This is the 'single writer principle' which is a variant of the 'single source of truth principle'. You can't have concurrent writing in this case.
If you have statefulness + mutability then you must do away with concurrency; a different way to avoid the same concurrent overwriting problem mentioned above.
If you have concurrency + mutability, then that's possible if you don't have state... You could have multiple independent, divergent copies of the state but not a single consistent state.
Last time I checked we had plenty of concurrency primitives allowing for that; you might need to wait few tens or hundreds of nanoseconds for a lock (or few orders more over network), but it works just fine
Dropping interactivity [keep Concurrency, mutability]:
The most popular choice is to drop interactivity: since there is no one to randomly access runtime data, there are no concurrency issues. C, Rust, Go, the list of languages that go this way is long.
Dropping mutability
What if you could not really change data? Instead of reading the value of a variable, you could have the runtime systematically (and safely) copy the value and return it to you.
Peeking over the fence at an immutable language and thinking "that runtime does too much copying, which is bad!" is like peeking over the fence at a GC language and thinking "that runtime does too many mallocs and frees, which is bad!"
They used C as an example because under normal circumstances you compile a binary and don’t modify it at runtime.
I’m not doing to defend it to strongly though, I _think_ that is what they were getting at, but to be honest I found much of it confusing.