I recently conducted system resource starvation tests where a compile process spun off enough threads to soak the system to the point it becomes unresponsive. I did over 100 forced power off tests while the Btrfs file system was being written to as part of that compile. Zero complaints: not on mount, not on scrubs, not with btrfs check, and not any while in normal operation following those power offs.
If you want to complain about Btrfs, complain about the man page warning to not use --repair without advice from a developer. You did know about that warning, right?
The only difference is that none of the repair tools were able to recover the filesystem, but I was able to dump the files themselves to a new disk to recover them. Really not sure why, it was very strange.
Once I ended up with a bunch of zero length files (presumably metadata was written before content?).
I also, multiple times ended up with errors related to full drives despite by drive not being full. Deleting snapshots seemed to help.
Then I went to a zfs fs on root and never had another problem.
My quite large 1tb multivolume, multisnapshot BTRFS fs never had any problems.
And it's quite aggressive cfg (big fs commit).
P.S. I do have backups though.
Why not putting poweroff in a cron task a bit before midnight so you don't uselessly risk hosing your file system? You can always restore your backup but it takes time!
[1] https://arstechnica.com/information-technology/2012/07/netfl...