The Solaris ZFS Best practices document answers this question:
A pool that is not created with ZFS redundancy (RAIDZ or mirror) can
only report data inconsistencies. It cannot repair data
inconsistencies. A pool created without ZFS redundancy is harder to
manage because you cannot replace or detach disks in a non-redundant
ZFS configuration.
As zfs send/recv overwrites data (if the correct flags are used), it depends on your situation if this is a concern. For example, if you transfer new blocks every 5 minutes and your main pool dies 2 minutes afterwards, the possibility for corruption is much lower than when the backup pool is only updated once a week, month or even longer.
Hardware availability may also be important: what if your backup disk dies (no problem, you still have the main pool), but you cannot replace it for a day, so multiple planned backups will now fail? Redundancy also helps at the hardware level, not only for data integrity. Of course, this does not matter much if you have two other such machines set up which continue to work.
An alternative for special usecases (only one disk possible because of space or port constraints, pool size less than half of maximum disk size) could be to set copies=2 for the backup pool. This way, the data is internally duplicated in the backup pool (requiring 200% space) and it gives you data integrity, but a hardware fault will still destroy your backup pool. It may nevertheless be useful for long offsite backup storage where only single disks are possible, or for smaller systems. Note that it does not work for existing data, so a full backup afterwards is needed.
Also, a word of warning from the linked guide:
If you store ZFS send stream on a file or on tape, and that file
becomes corrupted, then it will not be possible to receive it, and
none of the data will be recoverable.
This means, unless you have good reasons not to, you should use send in combination with receive, because only active imported pools can be checked for corruption. If you just want to store the stream (for example, if one destination pool should hold multiple streams at the same time), it is suggested to use zstreamdump to verify integrity.
