You almost never want to run btrfs-check. In itself, Btrfs is fairly "self healing", and only if you run into "weird things" in the log like invalid index files should you run check, and almost certainly never with the --repair option.
The thing about Btrfs (and ZFS) is that it is Copy-on-Write, and as such, new data is written to an unused part of the filesystem. It doesn't need to modify structures of existing data, thereby reducing the risk of bad metadata.
A file in Btrfs is either written or it is not. If a power outage occurs after a file has been written, but before the metadata is updated, the file is not written, and in case you're updating a file, the old file is still preserved.
If a crash occurs while writing metadata, Btrfs has multiple copies of metadata, and is able to repair itself online.
In the most typical case where you have a crash or power failure, you just reboot normally. No file system check happens nor is it needed. It just continues from the most recent successfully committed transaction. Since it's copy-on-write, there's no inconsistency in the file system, even if the most recent changes might be lost.
If you're not using RAID5 or RAID6 for metadata, the write hole won't affect the filesystem structure and there shouldn't be any issues for btrfs-check to find.
The relative benefits are discussed in "man 5 btrfs" in the "CHECKSUM ALGORITHM" section.
man 5 btrfs | col -b | sed -n '/^CHECKSUM/,/^FILESYSTEM/p'
Note that btrfs-scrub (according to the docs) is looking for on-disk block errors, comparing the data to the CRC (or whatever algo) to see if that matches. If it can recover the original data, the bad block is re-written with the correct CRC.
So btrfs-scrub does not find or fix any errors with the filesystem structure.
For that you need to run btrfs-check, and that can only be done offline.