ZFS relies heavily on Solaris VFS API, which is inherently different from both Linux's VFS and FreeBSD's VFS implementation (e.g., behavior of vnode[1]). Both FreeBSD and Linux implements this VFS API with a layer called Solaris Porting Layer (SPL).
In the original Illumos-based FreeBSD ZFS, this SPL layer was implemented as a kernel module (opensolaris.ko). OpenZFS originally maintain this shim in other repo, but later incorporate this shim into its codebase. FreeBSD port of OpenZFS involved importing SPL layer from FreeBSD tree into OpenZFS. On this part, there's not much difference in nativeness of the port.
However, this SPL layer also serve the purpose of adding one degree of separation between GPL code and CDDL code in order to comply with GPL in order to prevent ZFS code from becoming a derivative of the Linux kernel. The shim in OpenZFS is in three licenses; the Linux part of SPL is GPLv2, the FreeBSD part is 2-BSD, and the part that interacts directly with ZFS code is CDDL.
This is the area where FreeBSD can be more native with regarding to ZFS. Since CDDL is compatible with BSD license, FreeBSD kernel and its userland can integrate directly with ZFS without any licensing issue, e.g., FreeBSD bootloader can simply linked against ZFS, whereas GRUB2 must reimplement a part of ZFS in order to do probing.
[1]: https://wiki.freebsd.org/AndriyGapon/AvgVfsSolarisVsFreeBSD
There's other OS specific features that FreeBSD does better with regards to ZFS such as ACLs too. But like with trashed volumes, they're edge cases.
FreeBSD also has better bundled tooling for working with ZFS. By this I don't mean `zfs` and `zpool` but little shell scripts et al that are FreeBSD specific.
Then there is the documentation. If you're running Linux then all the documentation regarding server management is about standard server management (ie with an ext4 or xfs root). But FreeBSD documentation will talk about how to do management with the assumption you're running ZFS. The FreeBSD docs (which are excellent, by the way) has pages and pages on ZFS outside of the stuff published by ZoL (which is pretty poor it has to be said) and OpenZFS. And I say the last points as someone who's had to manually compile kernel modules on Linux to get the latest patch to support a feature that made it to FreeBSD first.
I do have servers running ZFS + Linux and they work really well. So I'm not taking anything away from that architecture. But when things go wrong or you're trying to do something a little more specialised outside of basic file storage, ZFS has always felt like an awesome hack on top of Linux rather than an integral part of it's design. Unlike with FreeBSD where the same people managing the kernel and userland are the same people pushing ZFS as the default file system. If Torvalds, Pottering or others held ZoL in the same esteem then I'm sure the edge cases I've described would go away (Linux certainly has the larger developer community).
One of the experiences is very much "native" - the other is possible, but a GIANT pain to accomplish.
At some point I'm sure, Ubuntu at least, will make installing to ZFS on a server OS more straightforward. I've got several systems doing it today, but I can tell you it's not for the faint-hearted and it took a TON of trial and error to get it to do what I wanted consistently. I also cringe every time I apply an update because I know it's not something that is getting any significant testing by Canonical or the community at large.
ZFS as root is completely normal on FreeBSD, is it on Linux? You have tools like zfs-stats, bectl, zfs or dataset-jails, poudriere (packagebuilder) fully integrated with zfs, the list goes on and on. So even when the base of OpenZFS came from ZoL, it's use on freebsd feels much more integrated...or let's call it native.