His issue isn't with ZFS, it's that most parity raid (raidz, raidz2, raid5, raid6, etc) doesn't support safely rebalancing an array to a different number of disks.
With mirrors, the things he describes aren't an issue, especially in a home server. You can start with one disk, mirror it when you're ready; then add additional vdevs of mirrored pairs extending your pool as necessary. Or upgrade two disks to grow a vdev.
Each "Home NAS" is going to have very different requirements (to each his own).
If you are concerned about reliability and want to be protected against a dual-drive failure, you're better off with RAIDZ2 than with a bunch of striped mirrors, because with RAIDZ2 you can have any two drives fail, where as with an array of mirrors you still have this nagging chance that the second disk in your degraded VDEV will fail and you will loose the entire pool.
Chances are that your home NAS does not have a 4-hour disk replacement SLA.
Also, just blindly recommending to mirror everything may not be the best option for a lot of home users that don't want to loose half of their raw capacity to parity.
Sun apparently had internally done most(?) of the work on BP rewrite (as it's referred to), but performance sucked rather badly, and the work has not been shipped by Sun/Oracle, let alone anything that came out before the F/OSS code sharing ceased. 
(Performance sucked, in particular, for similar reasons to why dedup performance has such a high penalty on ZFS - they end up storing a lookup table that gets hit for every block that gets written after you turn on dedup, and so if that table stops fitting in RAM, it's a bad time - let alone the issue of making sure the disk backing the DDT storage is sufficiently performant...)
 - http://www.listbox.com/member/archive/182180/2012/01/sort/th...
Nowadays, RAID5 is deficient.