I think the complexity of btrfs and its mix of device and file system layers rules it out for general purposes.

The file format is very simple. The write guarantees of the file system for full OS usage may not be simple, certainly they're not simple on Linux, and Btrfs development shows that this is hard.

The GRUB Btrfs driver is pretty small considering the Btrfs feature set. And yet it understands all the multiple device stuff, the logical and physical device abstraction, and snapshots and subvolume navigation.

I like always on checksums for every block, both metadata and data. It's a good fit for the cheaper flash media out there including USB sticks which non-deterministically report back garbage, rather than a discrete read error.

Why?

I use it on my laptop with 0 issues. It’s really not that complicated...

It's not about that - the filesystem needs to be simple snough that multiple vendors' implementations will be compatible.

Remember SOAP interoperability? Me neither. It was too complex for its own good. That's why REST is used everywhere today and experienced web developers smile every now and then when they remember they don't need to use it anymore. Well, most of them at least...

I’m not talking about complexity to use but rather architectural complexity. Rather than being a simple fs driver, it (in the ZFS model) consumes raw devices then re-exposes them as software-defined volumes optionally with a file system api already exposed or as software defined block devices that can then be formatted with another filesystem.

It basically upends the entire separation of layers and requires a completely different approach to use.

Btrfs actually has a simpler interface than ZFS: it consumes block devices and exposes only a filesystem, not more block devices. It does have integrated volume management functionality, but overall acts much more like a "regular" filesystem than ZFS.