Yes, the data has to be decompressed and then compressed again.
See, the data compression is based on how the internal storage works, not on SQL data.
But you work on SQL level here, so the data has to be made available for SQL (materialized) and then needs to pass through the SQL layer again to be stored in the target data structure.
There the data can be compressed again.
That' the same whatever you do with compressed data. If you want to copy a ZIP archive but modify what's inside the archive, you need to uncompress it first.
Anyhow, nothing to say against a layered data loading approach (although you might consider a delta loading option when you deal with this kind of data size... ). However, when this really is just a movement from staging to target table, then you got all options to split up the data transfer in multiple chunks. That way you could even parallelize the loading by a higher factor.
And sure enough, that is something you could model with DataServices, correct.
And nope - the counters for the memory sizes of delta and main memory are only updated after a transaction ended. There's no point in "watching the filling of the delta store" or something like that - it's a shared resource anyhow.
So, rather chunk up your data load in manageable sizes and don't worry about the delta store anymore.
Alternatively: by a larger machine + license 