I've used ZFS as my primary data workstation FS (as opposed to NAS), first under OS X and then FreeBSD, for over 4 years now, and amongst the many benefits backup/replication definitely rates highly for me. But while I'm interested to see native send/receive in the cloud, particularly once resumable support makes it into mainline OpenZFS, I'm actually not sure how useful it'd be in general for plain backup purposes. One of the most valuable choices Sun made in send/receive was that it uses normal stdin/stdout, and that in turn can give ZFS immense flexibility in terms of cloud storage targets. While I do local online replication to a NAS, for remote backup I just dump to files. Simplifying here without all the exact options:

  zfs send tank@snapshot | lz4 | openssl enc | par2 > file

OpenSSL of course using AES-256 and a key, and par2 adjustable based on characteristics of the target storage. This is part of a simple script to produce and cycle incrementals. The result are an original and then set of deltas that are client encrypted and have some redundancy even in the face of errors in the foreign filesystem or transmission process, and thus can be used practically anywhere with minimal thought towards remote security, no need to trust any sort of closed client or service, etc. It works nicely with Amazon's offerings (including Glacier), particularly since they allow actually physically sending in a hard drive which is really handy for freelancers or small businesses with significant datasets but highly mediocre netlinks (ADSL 5/1 or some equivalent is still depressingly common in America at least). Since par2 can also split output to arbitrary sizes and numbers, it'd be possible to use this workflow for anything from optical to storage lockers as well (dataset size permitting).

Really, with stdin/stdout the sky is the limit, and there are minimal ties to any specific service since only the most generic raw cloud storage features are being used.