ZFS on FreeBSD has been flawless for me. ZFS on Ubuntu is functional but limited, and I've experienced some odd glitches.
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.
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.
1) There is a clear separation between the base system and the extra software. On a typical Linux distribution, everything gets installed into /usr, /etc, /var, etc. On FreeBSD things that aren't part of the base system go into /usr/local.
2) The base system is designed as a whole cohesive system. The kernel and userland are kept in sync through the update process.
3) The documentation is fantastic.
It would be unfair to Linux if I didn't mention some downsides though:
1) Upgrades are more painful than Linux, and more painful than they need to be. On my OpenSUSE boxes, an upgrade is literally "sudo zypper dup; shutdown -r now". On FreeBSD, the same task requires multiple reboots[0]. Then you need to update any extra software as a separate step.
If you have a custom kernel (because you needed IPSEC and/or NAT-T), it's even more painful.
2) The base system is fairly sparse. You want to use bash? That's an extra package. Want sudo instead of su? That's an extra package. Don't get me wrong, the base system is very usable, but it does lack a lot of things that Linux users take for granted.
[0] https://www.freebsd.org/doc/handbook/updating-upgrading-free...
On TrueOS out of the box everything is ZFS, even the root volume, and that has been the case for a while, now. The operating system is in a single ZFS dataset (with things like /usr/ports, /usr/jails, /var/mail, /var/log, /usr/obj, and /usr/home split off into their own datasets). This is used to provide "boot environments".
System upgrade goes like this: The upgrade script makes a clone of the current operating system dataset, mounts it, and runs freebsd-upgrade on it chrooted at the mount point. This results in a new boot environment with the upgraded operating system ready to be rebooted into. ZFS copy-on-write means that an upgrade does not consume twice the disc space; and the separate dataset means that one retains an untouched current boot environment throughout the process.