I am running BTRFS on multiple PCs and Laptops since about 8-10 years ago, and i had 2 incidents:

1. Cheap SSD: BTRFS reported errors, half a year later the SSD failed and never worked again.
2. Unstable RAM: BTRFS reported errors, i did a memtest and found RAM was unstable.

I am using BTRFS RAID0 since about 6 years. Even there, i had 0 issues. In all those years BTRFS snapshoting has saved me countless hours when i accidentially misconfigured a program or did a accidential rm -r ~/xyz.

For me the real risk in BTRFS comes from snapper, which takes snapshots even when the disk is almost full. This has resulted in multiple systems not booting because there was no space left. That’s why i prefer Timeshift for anything but my main PC.

Tipps to prevent future accidents:

• Set up BTRFS snapshots with Timeshift or Snapper. Switching to BTRFS is worth it for snapshots alone.
• Do regular backups on a device that can not be reached by rm: vorta local on external hdd that you connect once a week OR vorta/borg2 to a NAS/Server that does BTRFS snapshots itself OR Nextcloud to sync to a server that has a trashbin OR git to a server. Just remember that Nextcloud and git are unencrypted, so the server has to be secure and trustworthy. Vorta and borg2 can be set up with encryption.

Mistakes are unpreventable due to our error-prone brains, but it is a choice to repeat them.

If you are having sensitive information stored using closed-source software/OS, you can stop reading right here. This is your biggest vulnerability and the best thing you can do is to switch to FOSS.

For those that have already switched:
It made me think about how to improve the resistance of large FOSS projects against state-sponsored attackers injecting backdoors.

The best thing i came up with would be to have each contribution checked by a contributor of a rival state. So a Russian (or Chinese) contributor verifies a contribution by an American.
The verifying contributors would have to be chosen at random in a way that is not predeterminable by an attacker, otherwise a Chinese-state contributor will contribute harmless code until the next verifier will be a US-based Chinese spy. Then they will submit a backdoor and have it checked by an American citizen paid by China.
Also the random number generator has to be verifiable by outsiders, otherwise a spy in the Linux-Foundation can manipulate the outcome of choosing a favorable verifier for a backdoor.

This can obviously only be done as long as there are lots of contributors from rivaling states. If the US decided that Linux can only allow contributors from USA/EU, then this model can not work and Linux would have to relocate into a more favorable state like Switzerland.

What one should keep in mind that even if the US would ban all foreign contributions and the foundation would not relocate, Linux would still be more secure than any closed source OS, as those foreigners can still look at the code and blow the whistle on bugs/backdoors. It would however be much more insecure than it is now, as the overhead for finding bugs/backdoors would be much larger.