One thing that raidz has going for it over a block level raid is that zfs knows which blocks are in use and recovery does not need to read all blocks on all disks to recover.
Zfs also prioritizes user reads and writes over recovery (resilvering), which may not be universal practice with RAID.
It's certainly still the case that if your redundancy drives failed, you're at greater risk of data loss, and IMHO, disk failure rate during repair is higher than base rate: maybe from extra use, but also because of the risk of correlated failures --- if your environment contributed to failure of the first N disks, the other disks were also in that environment and may be about to fail.
I think also that ZFS supports online rebuild. I remember in my data centre days that a few of the RAID5 products only did rebuilds offline. The HP/Compaq Smartarray stuff was the bees knees though; reliable stuff.
Almost all “normal” damage is and should be repaired online with zfs. Those offline repairs meant the hardware controller had no idea how to interact with filesystem directly, probably for the best. Level of abstraction purists don’t like this aspect of zfs.
If something particularly bad happened, or you tried being really “clever”, you can get into a rare situation of not being able to import the pool or have it import in read only mode. There are tools to help repair that kind of metadata damage. Then proceed with the normal online repair if needed.
Zfs also prioritizes user reads and writes over recovery (resilvering), which may not be universal practice with RAID.
It's certainly still the case that if your redundancy drives failed, you're at greater risk of data loss, and IMHO, disk failure rate during repair is higher than base rate: maybe from extra use, but also because of the risk of correlated failures --- if your environment contributed to failure of the first N disks, the other disks were also in that environment and may be about to fail.