The news that Apple is dropping ZFS does not greatly surprise me. While there's a lot of cheerleading around ZFS, some justified, some not, it would need a lot of work to play nice with the typical Mac customer. Apple brands on the whole "just works" thing. ZFS? ZFS is a bad fit for this. Consider some examples from Real Life on Solaris:
zpools grow, don't shrink
You can only ever grow zpools. Add disks or LUNs and decide you want to shrink again? Backup, destroy, start again. How intuitive is that? Can you imagine Apple explaining why you can dynamically expand your disk, but never shrink it to their "ease of use" customer base?
Don't cross the… fill the disk
Fill a pool to 100%? Oh dear. Oh deary me. You are about to discover an annoying, logical, and surprising property of ZFS. Since you write by appending changes, to ensure the atomicity of operations, you always need free disk to write proposed changes to the filesystem before you commit them. So if you need to delete some files to free up space in a full pool, you need to write some metadata before you... ahh, crap. Recommended fix? Backup, destroy, restore. Unless you're lucky enough to have some snapshots you can destroy, because they don't pre-commit metadata changes. They are the only thing you can remove that won't require preallocation.
The first time I encountered this behaviour I saw mailing lists with Sun engineers noting that the lack of an emergency reserve or some other mechanism to mimic the traditional reserve space created on filesystems in the Unix world was a bit of a design flaw, and the behaviour, while as designed, was shitty. They opined it ought to be fixed. In 2006.
Not exactly "just works", is it? "Just backup, destroy, and recreate your filesystem."
General Requirements
ZFS is hungry if you want it to work right. Various ZFS tuning guides I was reading in 2008 suggesed you can budget, depending on throughput, a half to a GHz of an UltraSparc VI[1] to drive decent performance if you use checksumming (which is a key selling point of ZFS). You ideally want a couple of gig for the ARC to get optimal performance, as well. If you're designing a server these are not likely to be requirements you think twice about. If you're buying a laptop or workstation you may have second thoughts.
Code Quality
I haven't looked at ZFS in a serious way in a year, so this may have cleared up, but back in 2008 I was stunned at how many kernal panic inducing faults were current in the then-current releases of Solaris 10u4 and u5. Add LUNs? Kernel panic. Remove LUNs? Kernel panic. Not all the time, of course, but there seemed to be a steady flow of hotfixes that were not what I'd expect from something being sold as an enterprise filesystem. I hope that's improved, but I can understand Apple's reluctance to deploy something which, on the face of it, had been pushed to market in a hurry (just ask Joyent!).
[1] A half-arsed metric, I know, but whatever.
