As to my best knowledge the algorithm within the rsync tool will slice the file and compute for each slice a hash. So I assume that there are files where the hash algo will rebuild a file without actually transferring less data. I suppose a file with only zeros will be a good candidate, right?
The rsync algorithm is more sophisticated than that. Hashes for file slices are computed for the remote file and transmitted to the local rsync. The local rsync uses these hashes to find matching file sections in the local file anywhere they occur. These matching sections are not transmitted; tokens telling the remote rsync how to reproduce these section are sent instead, which is how rsync avoids transmitting the whole file.
So, optimal files for rsync are those with vast swathes of data in common, perhaps shifted by insertions and deletions, e.g. the sorts of files produced by typical human editing activities. This is unsurprising since, as rsync author Andrew Tridgell wrote in his PhD thesis, he began considering the rsync algorithm while waiting impatiently for program source files to be updated over a modem link.