As a (semi) power user I also use btrfs subvolumes to create “partitions” (single disk system, @root, @home, @docker), allows for making snapshots only for system or user data, etc.

All around, I love btrfs and I am never going back to journaling fs like ext4

Copy on write is likely to introduce significant performance decreases in cases where large or medium size files have a couple bytes changed. It’s usually recommended to turn CoW off on those files; I found it to be more hassle than it’s worth for a root filesystem. It is still a reasonable file system for file storage that looks more like archival - files land there and seldomly or never change. If you don’t have a specific need in mind though, I wouldn’t bother - in my opinion, it’s not great as a general purpose filesystem.

If you don’t think you want snapshotting then dont worry too much about it and use whatever fs you like. if you want a nice btrfs experience try tumbleweed or leap, it is already fully integrated with system and grub , and maintenance with cleanup etc. cobbling together btrfs on your own is fine too but if you miss sometging and mess things up it is usually user error not btrfs error. .

Yes, snapshots nice to have and compression reduces the disk usage for the operating system and software quite a bit.

Transparent compression, snapshots, copy-on-write, deduplication, and data checksumming (and healing via read or scrub) are the main things you might notice as an end-user. BTRFS is mostly on par or slightly slower than other simpler filesystems for speed (can be faster on HDDs due to compression), so if you’re using it you probably want to be taking advantage of the features it offers, not because it’s going to be faster.