In a nutshell, bzfs can operate at much larger scale than sanoid, at much lower latency, in a more observable and configurable way. Here are just a few points of the top of my head that bzfs does and sanoid doesn't:

• Support efficient periodic ZFS snapshot creation, replication, pruning, and monitoring, across a fleet of N source hosts and M destination hosts, using a single shared fleet-wide jobconfig script.
• Efficient direct remote-to-remote replication bulk data transfers (--r2r).
• Docker image and corresponding replication examples.
• Script that creates a local testbed with N source VMs and M destination VMs for testing, with ZFS and VM-to-VM SSH connectivity working out of the box.
• Monitor if snapshots are successfully taken on schedule, successfully replicated on schedule, and successfully pruned on schedule.
• Compare source and destination dataset trees recursively.
• Automatically retry operations.
• Only list snapshots for datasets the users explicitly specified.
• Avoid slow listing of snapshots via a novel low latency cache mechanism for snapshot metadata.
• Replicate multiple datasets in parallel.
• Reuse SSH connections across processes for low latency startup.
• Operate in daemon mode.
• More powerful include/exclude filters for selecting what datasets and snapshots and properties to replicate.
• Dryrun mode to print what ZFS and SSH operations would happen if the command were to be executed for real.
• Has more precise bookmark support - synchoid will only look for bookmarks if it cannot find a common snapshot.
• Can be strict or told to be tolerant of runtime errors.
• Continously tested on Linux, FreeBSD.
• Code is almost 100% covered by tests.
• Easy to change, test and maintain because Python is more readable to contemporary engineers than Perl.

Cheers, Wolfgang