The reason is that (a) zfs send/recv is very fast and can be done on an hourly (or even faster) basis even with billions of files, but file-based replication (e.g. rsync or rclone) is typically slower with large file counts. We can afford to have a slower pipeline to the offsite-storage.
(b) I wanted to prevent some kind of ZFS bug in send/recv handling accidentally transferring corruption from the original data store to both backups
(c) Depending on the zfs send/recv flags that are used, it can remove snapshots not on the source host. So there is scope for both accidental and malicious deletion of all snapshots depending on the circumstance.
(d) You don't want all files being removed on the source to remove all copies in either the backup or offsite-backup location. That is the reason the offsite-backup had it's own point-in-time snapshots so that if all of the files are deleted from the source + backup, when the offsite-backup replicates that state and removes all of it's files, you can still access the files from the previous point-in-time snapshot.
(e) You don't want a hacker that penetrates 1 of the 3 storage locations to be able to cause or directly access both of the other 2 locations. This is commonly possible because SSH keys are used to allow zfs send/recv or rsync. Pivoting from a production storage to all backups (and destroying them) has happened in some high profile malicious cases, e.g. Distributed IT.. At a basic level, this means for example your backup server can't directly co-ordinate both the local and offsite backups via SSH otherwise it may have direct access to both environments and if the backup server is compromised.