ZFS does not have things like chkdsk or fsck because it is impractical to do these operations on a tiny computer, even if you think your 128 core 1TB machine is "huge". ZFS filesystems often range into the multipetabyte range. Consider this:
Let's pretend that the hypothetical 128C/1TB system I just speculated about has 4PB of storage. If we were to break that down into 4C/32GB systems, we would end up with 32 separate systems. (4C x 32 = 128C, 32GB x 32 = 1TB). Now if we split the 4PB up into 32 chunks, that'd be 128TB per system. Is 128TB even practical to fsck or chkdsk on a 32GB 4 core system? And if not (it's not), how is ZFS supposed to manage that trick for something 32x larger? You need a HUGE amount of memory and resources and it'd also take... forever. This only gets worse because ZFS has incredible CoW features such as snapshots and clones that substantially increases the metadata complexity, which means the system has to work much harder to validate the correctness of the structure.
ZFS works super hard to protect against introducing failures into the pool in the first place because once an error is introduced, it may be virtually impossible to expunge, especially if it is in something like metadata. This is why ZFS users need to be a little paranoid about things like using well-supported HBA's, and favoring ECC memory, because once crap data is flushed out to the pool, it could potentially do permanent damage to the pool, with the primary recovery option being "use your backups". On the flip side, if you play the ZFS game the way the designers intended, your data is quite safe compared to a conventional filesystem.
