Btrfs lets you keep metadata at a stronger bitrot-protection level fairly easily, and as long as that is still ok, you'll only use the data blocks that rotted, so at LTT's scale just a few seconds of footage in total.
This isn't easy code to write, and it's Linux-Kernel-C, far from "comfy" code to write. I assume it's that kind of effect that continues to keep all competent people from fixing Btrfs's RAID 5/6 code. (If I could gather the motivation, I could probably do it, but that's far from fun to do and I'm already dire for motivation-to-code... it needs to be someone who likes that work, ideally sponsored so they don't loose money from working on that project.)
I really have no idea what BTRFS feature this refers to, but ZFS stores redundant copies of metadata. See: redundant_metadata, https://zfsonlinux.org/manpages/0.8.0/man8/zfs.8.html
See how one converts here: https://btrfs.readthedocs.io/en/latest/btrfs-balance.html
BTRFS stores duplicate copies of the metadata. Good for BTRFS. I don't understand how this would have prevented what LTT experienced.
First, as someone else said -- no one would use a BTRFS raid5/6 array in production. No one. Second, I don't think what LTT experienced was bit rot. There were far, far too many data errors for that be simple bit rot. My guess is bad cable, bad HBA which maybe doesn't support something like ASPM, etc. Third, are we even sure the problem was corrupted metadata? Fourth, ZFS keeps redundant copies of metadata too (as do many filesystems.)
So the question is what's your point?
I know no one would use Btrfs raid5/6 in production, but that's because no one wanted to enough to get the required development done.
If it was just file blocks that got corrupted, there would be just very minor damage in total and a scrub that logs all damaged blocks typically proceeds at sequential read speeds from what I've observed in the past.
They made severe errors in judgment when setting up the system and failing to monitor and administer it. No system will ever protect against this. Not ZFS. Not btrfs.
Oh, you meant no one with a shred of responsibility, which I agree with.