A filesystem corruption bug breaks loose

You still need to balance one data block group every now and then, just enough to keep one chunk unallocated on each drive. A partial or full rebalance is required after some array layout changes (and always will be--the best outcome would be to automatically start a balance when that occurs).

Parity RAID now survives data corruption and non-timeout IO errors. It will happily--and correctly--fix itself even if you corrupt one random byte on every block of two disks in a RAID6 array (except nodatacow files, which will be corrupted because nodatacow intentionally trades detection or repair of data corruption for performance). I haven't tried it with real failing disks, though, and I lack the imagination and contempt for data integrity required to try to replicate drive firmware bugs in a VM.

That said, there are still hundreds of other bugs, and there are still plenty of opportunities to improve performance in btrfs.