On the contrary, it's quite true. I'm a little disturbed by how readily people ascribe nefarious intent to assertions regarding things they have not experienced themselves. You might not have experienced problems, but that does not logically imply that it is free of problems.

A few months back, I booted my Ubuntu 16.10 workstation. No ZFS datasets were mounted at boot. Regular "zfs mount" and "mount" failed. Could not get the datasets to mount at all, even though the pool was active and the datasets were visible. Solution: changing the mountpoint worked for some reason. Still no idea what triggered this or why the fix worked. Either way, it broke the system's normal functioning through no intervention of my own.

I've also had the zfs and zpool commands get stuck in "D" state indefinitely because something internal had blocked everything. Mounted filesystems continued to work, but no admin commands would work. Triggered by running some trivial admin function. After a few days I had to hard reset the system to regain control. This looks like a locking bug.

I've also had poor behaviour when a disc glitched and I got an oops rather than ZFS coping with the short outage. IIRC I got the same "D" state issue as above.

I never encountered any such problems with FreeBSD, and I've run it on both platforms for years. ZFS on Linux is functional, and I use it daily, but the FreeBSD implementation is better.

Maybe ubuntu is just as usual buggy junk? Anything other than lts can usually be assumed to be problematic.

I think its worth noting that 16.04 is is 16 months out of date on zfs releases and even 16.10 is 10 months out of date.

In a version of software in development the most current stable release potentially has a lot of bug fixes that ubuntu users are missing out on.