Btrfs is slower than lvm+ext4, doesn't like working with large files, requires more ongoing maintenance (scrub, rebalancing), and is more prone to data corruption. Given that lvm can do snapshots under ext4, the only real benefit of btrfs is btrfs send, but for most use cases that doesn't seem like a large enough benefit to be worth the rest of brtfs' drawbacks.
Subvolumes: "Lightweight partitions" allow you more easily to define the scope of a snapshot. With ext4+lvm you have to create a new partition and logical volume.
I don't think, it is a big game-changer, but then I don't think, the other things are such dealbreakers as many people think. I consider "is more prone to data corruption" as largely historical/anecdotal.
Btrfs send sounds appealing, but personally, I prefer my backup solution to be independent of the filesystem.
If there's no LVM, most point-and-click tools allow for resizing a partition and a contained filesystem in a fairly simple process. (Having a LUKS encrypted volume might complicate that, but if the encryption is on the filesystem level, that could also be avoided.)
People who dual-boot might also need to resize their partitions if their needs regarding the operating systems change, or if they made a mistake in their original allocations.
That's probably not enough of a reason to make a major switch, but it could be one task that could be simplified.
Looking at my disk in gparted now, while it shows the LVM physical volume (and would presumably allow resizing it if it weren't in use), it doesn't seem to show the logical volumes and their filesystems inside of the physical volume at all. The partition information window for the LVM PV does list the logical volumes, but not the main window where you can plan the changes.
I don't know if that's a general limitation of gparted or if it's a peculiarity with my setup, but that's how it appears to me.
I'd challenge that. The main reason for using btrfs in desktop use is precisely is that your data is less likely to be corrupted. Specifically because unlike lvm+ext4, btrfs does full data checksums and therefore is capable of detecting silent data corruption.
I'm not sure that's a good description. Scrubbing is an option that you get extra. You don't need to use it and the behaviour won't be different than for example ext4 with regards to bad data detection. It's purely an extra feature.
If rebalancing is useful for desktop users (wasn't really in my experience), I'm sure it will get a system-provided job that balances the resource use and amount of reclaimed space.
https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-y...
There is some debate on this question:
https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=...
I'm curious if the situation is improved for BtrFS.
Instant, unlimited, zero-weight snapshots. You'd be surprised how often you use snapshots when you have them. A couple weeks ago I screwed up a save point in a game. Instead of just living with my mistake, I rolled my Steam directory back an hour.
Transparent compression.