By default, Rsync only synchronises the modified blocks and bytes. Therefore, if you had synced a text file before and later added some texts to the source file when you sync, only the inserted text will be copied.
If your using a uncompressed tar file and appending file to it with
tar -rf archive.tar file3.txt
then rsync will be able to just transmit the new differences at the end of the tar file.
However, if you creating a tar file from scratch, tar in some cases can be non-deterministic in the way it add files and directories to the archive.
It's quite possible that two tar operations on very similar file systems can create vastly different tar files in terms of underlying structure.
However depending on how great this non deterministic behaviour is, the rsync delta algorithm could find some wins.
The act of compressing the output to a .gz, will only make things worse. Compressing data is act of transformation, even adding a few extra byte's to a tar file and then compressing it, can radically alter it's entire structure. Thus defeating the rolling hash algorithm that rsync implements.
in may be better not to compress the tar file it self, but allow rsync to compress the data it send with rsync, --compress or -z
Tar is not deterministic because it's add padding, it does not sort files in a particular order and it adds timestamps, etc
Some systems such as Nix/Nixos use a deterministic archive format called NAR.
NAR is the Nix ARchive.
If you want to learn more about non-deterministic behaviour in archivers, and how this is overcome... you can find more in Dolstra's PhD Thesis.