Tip of the day: when copying huge files over scp, I highly recommend compressing with pigz rather than gzip.
Also, make sure you don't use too long of an ethernet cable, thus dropping the link speed. 100 Mb/s is damn slow these days.
You'll thank me later.
Okay, some context: decades in software and an obsessive-compulsive streak definitely go together. In my case, it means when I transfer my home directory to a new system, I want the file creation timestamps to be preserved 
More specifically, copying from the venerable ext4 partition on my laptop to the shiny new btrfs partition on my GPU-yoked mini tower.
First, I used rsync. Of course, I love rsync. But, contrary to the -N flag, rsync can't always deliver on preserving file creation times, not if the filesystem or OS doesn't support it. And Btrfs doesn't, and Linux doesn't.
Seeing my storied archive of... what the hell is in there anyway?... re-timestamped to 2023, I realized that wasn't acceptable. Those who cannot remember the past are condemned to repeat it, after all!
So here's the game plan: I'll somehow convey the 1.4 TB ext4 partition from my laptop into a file on the new btrfs partition. I guess scp might work (I'm trying as we speak - see above tips) but it's pushing the limits to do such a large file that way.
After I copy it over and check the md5sum, I'll mount the ext4 partition image via a loopback device, and run btrfs-convert on it.
btrfs-convert (for the uninitiated) will convert certain filesystems to btrfs in-place, including ext2/3/4, ntfs, and reiserfs.
I already tested this procedure on a small filesystem, and it seems to preserve the file creation times (ctimes), and also set the file "birth" time (otimes - introduced in more recent filesystems including btrfs) in the same way.
The next step is to use Btrfs' send/receive function to copy the converted partition into a fresh btrfs partition, recompressing as we go if possible, and perhaps leaving behind any inconsistencies left by the btrfs-convert tool? (Totally speculating there. This step might be skipped.)
Yes, that is the extent of the OCD!
Last of all, I will opine: it makes sense to have those timestamps be immutable. Probably comes in very handy in forensics situations.
But... it's silly not to be able to preserve the human sense of "file creation" time when moving between filesystems. If there's no will to add an API allowing file creation times to be set, then we need an additional timestamp representing a user-friendly, notional file creation time. Let's call it ntime for fun. It would be set initially exactly as ctime or otime (if applicable) but would be modifiable via a kernel API, allowing the value to be copied from one filesystem to another.
Perhaps that's a task for future filesystems; or maybe existing filesystems could achieve this through some sort of versioning.
ext5 and btrfs2, anyone?