The (open)SUSE use case is significantly desktop/laptop use case. They’ve been Btrfs by default on sysroot for six years. And for almost two years for /home as well, and report fewer complaints following that change.
Value of Btrfs for system root: compression, discard=async, data integrity.
Compression saves space, reduces write amplification, and can improve performance.
Most file systems today still don’t enable discards by default at mount time, mainly due to concern over firmware bugs. There is a problem with giving the firmware too many hints about freed up blocks, which slows down normal operation, sometimes badly. And there’s a problem with no hints at all, which can result in cheaper SSDs running out of blocks ready (erased) to accept full speed writes, and thus slowing down normal operation. The async discard feature in Btrfs is an answer to this problem. Enough hints to keep the SSD performant, without overwhelming it.
Data integrity means getting an I/O error rather than bit flip, or worse corruption, simply being left up as an exercise for user space to deal with properly (i.e. a crash, transient strange behavior, maybe further corruption - who is to say, we can’t even predict how random corruptions manifest in executables, libraries and configuration files). It’s a rare case but more likely to hit your data than the file system itself, because there’s more data on a drive than file system metadata.
Btrfs offers reflink copies, useful for container use cases with overlayfs. Sometimes snapshots are even cheaper than that, depending on the workload. And pretty much all of the original reasons CoreOS moved away from Btrfs in 2014 have been solved - the pernicious ENOSPC problems took a significant dive following the 2016 merging of a new ticketed enospc infrastructure. Since then it’s been about identifying edge cases. I never balance or defragment any of my Btrfs file systems, no incantations, no rituals, etc.
There does seem to be a significant performance hit to certain postgresql databases that Btrfs developers are looking at - but this doesn’t happen in every case and doesn’t happen with all database engines either. I roll my eyes at most Phoronix benchmarks but the SQLite benchmarks on kernel 5.8 suggest btrfs is neck and neck, or maybe even occasionally beats ext4, even without nodatacow set. Even without compression.
It is recommended that VM images have nodatacow set. But such per directory or per file optimization can be done on behalf of the user - we have a few ideas how to do that so, again, mortal users who have better things to do anyway, don’t have to mess around with it.