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.)
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).