The particular bug that sparked that warning was fixed a while ago, but as a precaution against "btrfs ate my data" stories they've removed the ability to create btrfs-raid from the CLI tools (you can still use md RAID with btrfs but you lose most of the benefits of btrfs that way).
The design of btrfs allows for mismatched disks to be used in an array, and the btrfs RAID will keep the right level of redundancy while using the maximal amount of space, e.g. with a 4 TB, 2 TB, and 1 TB drive:
mdadm will give you 1 TB in RAID 1, or 1.5 TB in RAID 10 (constrained by the smallest drive).
btrfs will give you 3 TB in RAID 1 (constrained by the sum of the smallest drives).
btrfs also allows per-subvolume raid policies. So you could, for example, give users an "archive" subvolume in their home directory. You could then mark this as RAID 1 or RAID 5 (because you don't care so much about performance) while the main /home filesystem is RAID 10.
Unfortunately the RAID code is all horribly broken.
Being able to have non-symmetric disk topologies with redundancy. I believe that md raid does not support that, while btrfs multi-device does (which is what I think of as one of the really unique features of btrfs -- not even ZFS can handle the sort of disk topologies that btrfs can).
md-raid absolutely supports that and synology has for a long time. They call it "SHR". You simply do raid over disk partitions to enable disks of disparate sizes.
The reason ZFS doesn't support it, and absolutely 0 enterprise storage devices support this is because as the disks fill up, you sacrifice both performance and redundancy. Synology won't even support it on their high-end devices for this very reason. They'll only do it on their devices targeted at home use.
