There are lot of missing parts. Everything beyond using it for single disks or with RAID1 is still experimental. It's slow for a lot of use cases like VMs or OLTP ( http://blog.pgaddict.com/posts/friends-dont-let-friends-use-...) and using nodatacow does not count!
RAID1 is implemented to use the oddness of the pid to decide which disk to read from... RAID5/6 have huge performance problems in certain use-cases. Write hole is apparently still a thing.
Quota seems to be still broken or difficult to handle, the tooling is not exactly nice or intuitive (this may change in the future).
Hardware failure handling is nonexistent - it can't detect a broken drive.
Lot's of other gotchas. Just read the mailing list. I've been fighting against btrfs for a while and I'm happy when I'm not having to deal with it. Works probably fine for desktop usage but don't bother stressing it - at the moment it will break horrible.
Lots of gotchas yes, but it's about as rare to see data loss on Btrfs as it is on say linux-raid@ list for mdadm or LVM and those are much more mature. More often is the case of some suboptimal behavior and the recommendation to get the data off the volume and onto a newly created one. Very inconvenient for some users to be sure, but also not data loss. About the worst I've seen lately that wasn't hardware related needed data scraped using btrfs restore (the tool the extracts data from an unmountable filesystem).
This hasn't been my experience. When an md array has lost a disk, I have added a new one and the array has transparently resynched in the background. No interruption in service or loss of data. When a Btrfs array has lost a disk, Btrfs oopsed the kernel, and stopped working. When I rebooted with the hardware problem resolved, it toasted both the outdated mirror and the up-to-date disk, causing irretrievable dataloss. Any attempt to boot the system led to Btrfs causing an immediate kernel panic. I had to put the disks into a system without Btrfs kernel support and use dd to zero out the Btrfs partitions before I could use them again.
That was admittedly a few years back, but it's still a long way from production use in many respects, while ZFS has been in production use for years and is well documented, has good tools, and is very robust. After several years of Btrfs problems, I gave up on it and moved to ZFS, initially on Linux and then on FreeBSD due to it being better integrated.
RAID1 is implemented to use the oddness of the pid to decide which disk to read from... RAID5/6 have huge performance problems in certain use-cases. Write hole is apparently still a thing.
Quota seems to be still broken or difficult to handle, the tooling is not exactly nice or intuitive (this may change in the future).
Hardware failure handling is nonexistent - it can't detect a broken drive.
Lot's of other gotchas. Just read the mailing list. I've been fighting against btrfs for a while and I'm happy when I'm not having to deal with it. Works probably fine for desktop usage but don't bother stressing it - at the moment it will break horrible.