I'm not sure if true rsync is a good fit for Amazon.
As I understand it, the standard rsync algorithm means the client computes hashes for each block of a file and the server computes hashes for its copy and sends those hashes to the client which means the client can determine which blocks have changed and need uploading.
That causes two problems for Amazon in that a lot of hashes have to be send down over the internet and also it takes processing power to calculate all those hashes which would increase Amazon's costs - which is probably why they leave it to third party providers who can charge extra for that feature.
As for the clones, they are obviously storing the hashes somewhere and the somewhere may vary depending on the clone. It would be possible for them to store the hashes as a separate object per file on Amazon or as a database stored on Amazon or they may store them locally and remotely.
There are advantages and dis-advantages of doing it either way. If the hashes are stored remotely in individual files, then it can be costly to be continually retrieving them. If the hashes are stored in a database remotely, then this database can become large and it can be costly to be continually retrieving and updating them. If the hashes are stored locally, then this helps reduce costs, but introduces other complications and problems.
(Of course Amazon have other services, so it would be possible to keep a database in Amazon DB)
As an example, I tried out one early rsync clone many years ago. This was not written to take into account of Amazon's pricing structure and was issuing lots of http gets to retrieve the hash of each block and since Amazon charge for each get, it meant that while the storage part of my bill fell sharply, the transfer part ballooned.
What do I lose by using duplicity + s3 instead of rsync + s3rsync + s3?
You lose the fact that with rsync you know you are comparing source files with your backup files. With duplicity and other clones, you are comparing your source files with a hash which was taken when the backup was performed. For example, it may be possible to access S3 directly and replace one of its files without recomputing the hash or updating the hash database.