I finally moved a box's root filesystem onto ZFS, and the reason is one feature: boot environments. The ability to snapshot the entire OS before a risky upgrade, then roll the whole thing back if it goes sideways, is worth a great deal when the alternative is rebuilding from backups at 11pm.
The setup itself on ZFS-on-Linux is more involved than mkfs and a line in fstab, but it is not the dark art people fear. A pool on the disk, a dataset for root with mountpoint=/, the kernel and initramfs in place, and zfs_root passed on the kernel command line. The initramfs needs the ZFS modules baked in, which is the step everyone forgets, and then it pivots into the pool just like any other root.
zpool create -o ashift=12 rpool /dev/disk/by-id/...
zfs create -o mountpoint=/ rpool/ROOT/default
zfs snapshot rpool/ROOT/default@before-upgrade
The gotcha that nearly caught me was the boot loader. GRUB has to understand ZFS to find the kernel, and it only speaks a subset of pool features. Enable something fancy on rpool that GRUB does not know about and you get a perfectly healthy pool that will not boot, which is a special kind of frustrating. The fix is to keep the boot pool conservative, or carve off a small separate bpool with only the features GRUB supports, and let the main pool be as modern as you like.
Was it worth it? On a server I patch regularly, absolutely. That @before-upgrade snapshot has already saved me once. Take a snapshot, run the upgrade, and if it breaks you roll back in seconds rather than reaching for the install media. For a throwaway box, probably not worth the ceremony. But for anything I care about keeping alive, it has earned its place.