Honestly, ZFS is the best thing on the (Free)BSDs only... On Linux it doesn't even use the page cache, and you conflict severely with L2ARC. I know there's a variety of people who don't care, but still for real users it's not an actual option.
I finally moved to btrfs earlier this year, and so far I'm glad I did.
I run raid1 on my primary array, and raid5 on my off-site backup array at my mom's apartment connecting with Tailscale.
Replication is with rsync and borg, not snapshots.
Yes, it's more painful to replace disks after a failure, but once you get a bit used to it, it's really no big deal.
On my main workstation/laptop the dedupe and compression work much better than my experience with ZFS.
I use LUKS / dm-crypt on entire drive partitions. Did that with ZFS too, and by the time ZFS got this feature I was already planning my migration to btrfs.
I like encrypting with LUKS, because I can have a drive configured with mine and my wife's password. Either one of us can take that drive, plug it in, and Gnome will put a nice graphical prompt asking for a password, then decrypt the drive and mount the filesystem.
If I get hit by a bus, LUKS makes it much easier for my family to get access to important data without having to have that data sit around somewhere in plaintext.
For me on Fedora, uptime is better and maintenance overhead is lower on btrfs.
The kernel fscrypt layer just needed a lot of refactoring first to support cow filesystems.
I backup my files with borg, but I still use snapshots during the Borg backup to ensure files are not modified during the process
Also a complicating factor with kernel upgrades is that while zfs release notes clearly delineate what kernel versions are supported that information doesn't appear to be meaningfully encoded in package metadata so if you use new enough kernels compared to the version of zfs for your distro it is possible to front run support. For instance 2.2.2 supports up to 6.6 but you could very well for instance install 6.7 and it might not work.
The somewhat broken thing is not encoding known data like which kernel is supported to automatically do the right thing in the packaging system not the filesystem. The lazy fix is to just manually handle kernel updates. The lazier one is to grab the release notes and update if latest kernel is <= supported.
Re btrfs raid 5/6, yes everyone knows about this, and this is why I have it only on my backup system. My primary data which holds 15TB of family photos and videos is on raid 1. The offsite is there only for the time my house burns down.[1]
[1] I watched my neighbor's house go up in flames 2 years ago, and it finally got me going on setting up remote backups. The fire spread to 3 other houses, and everything happened very, very quickly. No one got hurt, but multiple families got displaced for more than a year. Besides having backups , it's also a good reminder to have adequate insurance. One neighbor did not.
boot.kernelPackages = config.boot.zfs.package.latestCompatibleLinuxPackages;
L2ARC isn't typically recommended for many use-cases. Anyway, what's the conflict you're referencing?
This is the case on FreeBSD as well, ZFS uses its own cache, but UFS and I guess other filesystems use the kernel page cache.