This means that each subsequent recovery step is progressively more potentially destructive. btrfsck (or as it's now more properly known, btrfs check) has big warnings saying that --repair might cause more harm than it fixes. There are even more destructive options, like --init-csum-tree and --init-extents-tree which destroy redundant information that btrfs uses to implement reliability, in the hopes that it can fix issues where the code to read that information is buggy.
I tried all of these things. None of them worked, but they all progressively degraded the hope of eventually recovering this filesystem.
I would of course have liked to back everything up first, but not doing so was a calculated risk. The filesystem was simply too big: it would have cost me hundreds of dollars and taken several days just to be able to physically back it up first - and even if I had tried, it's not clear how I would have found an enclosure that could hold all the additional disks I purchased to make the backup.
The irony is that the operation which destroyed it was the only reasonable way I could fix this problem.