Article doesn't really answer the question. Why would I want to use the ZFS "sharenfs" feature instead of normal exports? NFS seems orthogonal to a disk-based file system's setup, and now I have to worry about configuration in two places. Is there some advantage in speed or security?
It's the same advantage as, for example, letting ZFS manage your mountpoints: the pool itself contains all the configuration related to the file system, including NFS exports. It'll allow the export to be inherited to child datasets, removed when the file system is removed, change paths when the file system is renamed.
If you'd rather manage them the traditional way, that's there too (just as ZFS offers mountpoint=legacy if you want to use fstab).
It's been that way since 2006 when ZFS hit production with Solaris 10 u2. It's nothing new. Works a treat, because it makes ZFS properties the central point of system administration for many mundane and disparate tasks, like compression, mounting, SMB, NFS, et cetera, without having to worry about implementation details or running additional commands.
Might help to think of the filesystem attributes as being ACLs restricting sharing, with the whole ZFS array being shared except where prohibited by ACL. Just that "no ACL" means "restricted." (That's basically how Windows SMB volume-sharing works.)
Plan 9 works like this. A file server that serves disk file systems (CWFS on 9fornt) can be made to listen for tcp/il connections as well as the ability to serve parts of a file system or namespace using exportfs (a file server itself).
I admit I hated this ZFS feature in Solaris 10 already, and it was the reason for more than one unaccounted leftover NFS share that ended up in bright red in audit reports.
That is because it was done by hand; if it had been done by a SVR4 package, it could have been easily queried by the existence of that package on systems, and removing them would unshare the NFS mounts.
