Suppose there is some bug in ZFS or the OS. Checksums will fail (problem is detected), but conceivably, there could be a type of bug that an fsck tool could fix, without having to roll back to a previous version. Another potential advantage is that a fix by fsck could be much quicker than restoring a complete backup.
OK. Suppose you are running a buggy ZFS, and it causes problems. Why would you trust a filesystem repair tool written by the people who wrote your buggy filesystem to fix those for you without causing more problems? If anything, I would trust the filesystem more, as it (one would hope) sees way more usage.
If your OS or disks are buggy, you are hosed, anyway, as that checking tool would run on the same OS and hardware.
You should look at ZFS as having a built-in fsck that is automatically invoked when needed.
ZFS should be able to restore a failure in a single block quickly. With fsck you have to unmount the drive to even check. If you have a bad write operation (in ZFS) it should be detected even before the block pointer is set.
I'm not too familiar with exactly how fsck works, but it seems to mainly stitch bad metadata back together so there's still no guarantee that your data is perfectly restored.
This would be especially true if a bad FS write operation caused the data to be corrupt.
If the data is really corrupt the FS doesn't have any inherent way of knowing what the correct data should be.
