* ZFS doesn't include fsck because it doesn't make sense when your FS is guaranteed to be consistent. fsck is for when writes go bad because the window is there for that to happen.
Your claim is like saying a an electric car doesn't make sense because how is the consumer would be confused that it doesn't have a gas tank.
You don't backup ZFS filesystems to tape. I don't know of anyone doing that. It's a weird statement. If you want worst-case-scenario backups, you replicate.
Of course with auto-snapshots setup, and the basic inability of ZFS to become corrupted (IME, never had an issue with v28), you wouldn't be more or less likely to do that as a consumer than you would be to buy an external HDD for your Mac and use TimeMachine.
The only reason it isn't for the typical user is that the typical user doesn't run Solaris or FreeBSD.
* "Never mind that ZFS assumes that hard drives works to spec"
I don't know where you got that. It's actually just the opposite. It checksums everything and includes several facilities to catch early corruption and address it before you ever lose data.
On top of that most ZFS arrays I've worked with are standard 1TB to 2TB SATA systems. Nothing particularly special about the drives. Early on that was one of the big selling points of ZFS. That it was built for commodity hardware.
I personally have pulled the power plug on 24 to 48 disk arrays, literally hundreds of times while under heavy load and have never once lost data.
Not that I haven't run into other issues a few years ago, but data loss due to sudden power loss wasn't ever one of them.
It's almost comically easy to lose data (again, IME) on an ext3/4 system under the same scenarios. That's comparing zero ZFS losses to maybe a dozen of ext losses over the past 3 years.