I'd avoid using standard RAID levels in the context of zfs. They are only very vaguely analogous to zfs's various vdevs.
I don't think we disagree on much other than terminology for most of your comment above.
However, on the point of "one big zAB", I meant giving both disks to a single pool, rather than giving it two slices on each of the disks. Grow "zAB" by adding two more disks at some point. It's safer than any approach that involves fiddling around with GPTs. It's pretty easy to wind up with alignment problems that will hurt performance, and insufficiently difficult to wind up making all the pools wholly unimportable, or winding up with a pool whose layout is not what you wanted and which cannot be changed (time for zpool destroy, whee). Also, it's much harder to keep the data in the pools available and replicated during the grows.
That said, well, it's your data and system, and you can actually do what you propose with zfs. It may even be the right set of tradeoffs for you.
I think growing a pool with mirror vdevs is almost always going to be a better tradeoff for a home user who wants to grow pools like you, as argued here :
http://constantin.glez.de/blog/2010/01/ ... still-bestOn the point of pools that are sets of mirror vdevs, yes, pools that are one or more raidz2 will almost always have higher data availability figures, and raidz3 even more so.
*Availability* is the key here : it's a question of whether you can still use your data, live, as devices fail partially or wholly.
No pool, no matter how redundant, should be treated as "so safe I don't need backups", since you are unprotected from
(for example) accidentally supplying the wrong dataset, snapshot or clone to a "zfs destroy".
(On the other hand, multisided mirrors improve reliability as well; a pool with each vdev being a 4-disk mirror has even higher availability figures than raidz3, but it's hard to imagine any home user building even a single 4-disk mirror vdev).
It's unlikely that a home user would need that much of an increase in availability, unless the backup strategy is to have a large (and probably relatively slow) second system with a raidz3 (say) be the target of zfs send fastpool/dataset@snap | ssh ... | zfs receive -u safebutslowpool/dataset pipelines.
There is nothing wrong with having only numerous small pools either, other than your free space being scattered around a number of different pools and attendant "where am I going to put this great big blob of data now" and "where am I going to put this pool's backups" problems.