Cifs is implemented at a lower level in the stack than Samba; the primary upshot of this from my perspective is that you can only export a files in a single file system using cifs. If you have one file system mounted on a path within another, or symlinks that cross file systems, they will appear as empty directories or broken files, respectively. Given that a major reason for using ZFS is the ease with which you can use multiple file systems with different configurations all drawing from the same storage pool, this is a pretty severe drawback.
The flipside is that you get coherent oplock and sharemode locking with NFS and local accesses, reasonable ACL/identity management solution across all protocols, efficient support for file change notifications, etc. For these reasons I consider the in-kernel solution to be far superior feature wise as well as performance wise.
Oplocks are an optimization I'm not in much need of; 100MB/sec transfers do just fine. That sharemode locking is by and large ignored I consider an advantage of Samba, as in my personal environment, I do not care if some program wants to exclude readers or writers, I prefer to make those choices. I don't have any applications that treat files on a file share as a multi-user database like the era of Paradox etc.; those days are long gone.
I think ACLs are a bug, not a feature. They are too complex to administer both correctly and efficiently; a capability-oriented approach would be better, but that's fantasy, alas. Again, POSIX permission bits do just fine for my use cases.
From my point of view it's the single biggest drawback of OpenSolaris (and descendants) as storage servers, but I see no fundamental reason why it couldn't be fixed; it simply wasn't high enough up Sun's list of priorities.
