The short answer is, it's not a copy; it's just "different".
The long answer is, the SwapCache is actually pages that are pulled out of swap (using the term "swap" generically, regardless of the backing store, where zram and HDD swap are two examples of backing stores) and are temporarily decompressed while they need to be actively accessed. Remember: pages in compressed RAM cannot be directly accessed, because the data is compressed and is therefore unreadable (well, unreadable if you want to read the original data). So it has to be stored somewhere when the system says "OK, now I need a page from the compressed cache!". If you decompress it "on the fly" every single time you need anything from zram, that would be extremely CPU-intensive and probably result in an overall system slowdown that'd be worse than reading from swap on the hard drive. So the system keeps a cache of some of your swapped pages in memory, where "some of" is defined by the pages that were most recently needed.
Also, in case you intelligently point out that pages swapped out to the hard disk are not compressed: swapcache is still used there, because instead of a high CPU overhead on accessing those pages, you get a high latency while waiting for the HDD to seek and fetch the sectors and return them to memory where they can be added to the swapcache.
This management strategy allows you to optimize for a use case where you start up a lot of programs; push some of the programs' working sets into compressed swap as memory pressure increases (zram); then decompress the working set of individual programs (a program at a time) into uncompressed swapcache, when/if you access that program in the foreground or if it executes some background activity.
This is not too dissimilar from how swap works in general, regardless of its backing store (compressed cache in RAM or in swap). If you had a real slow hard drive with a lot of programs open and a lot of swap space used, you would notice the following symptoms:
Generally good performance on the "foreground" program (the window that you're interacting with right now)
A long delay and lots of audible disk grinding when loading up any programs that have been in the background for a long time
So what you're getting with compressed RAM in lieu of HDD swap is that the "long delay and lots of audible disk grinding" is avoided when you bring that background program to the foreground. Instead, the CPU goes wild with running decompression over the compressed pages, and it temporarily stores them in the swap cache while you're accessing the program, so that accessing the same compressed page several times doesn't lead to CPU-intensive decompression each time. But personally I'd much rather have higher CPU activity over high disk I/O and the accompanying latency.