I'm still not sure I fully understand what's going on at the low-level, but there is a "How it works" section on the debcow github page that at least made an attempt to penetrate my skull.

Edit: I guess the main thing it's doing is skipping the .tar archive extraction, and ref-linking the raw bytes from the .tar into new files? Extacting the .tar normally will create standard files, and those files would be reflink copied to the new location, but that still requires a more or less "normal file copy" during the .tar extraction. This really has greater implications for allowing generic reflinking from .tar archives, instead of just being limited to package installation. Could be interesting if it was handled automatically during .tar extraction. Or I could be misunderstanding, which is equally likely.

This isn't a basic copy of a whole file. This is creating a new file from a portion of an existing file.

A normal copy consists of a program reading from one file and writing to another. There is no way for the filesystem to do a reflink in that case, it just sees that the program is reading and writing stuff. In order to do a reflink, the program must tell the filesystem what data should be "copied" to where using FICLONE or FICLONERANGE. Though some programs will do that by default if possible nowadays when copying files or when moving files between different subvolumes on the same partition, including the Coreutils cp, mv and install commands and some GUI file managers.

Fragmentation is a big one on mechanical harddrives. If you have 1000 video files that all share half of their pieces with each other, the disk is going to seek like crazy between them instead of reading sequentially during playback.