Thanks kernow
I'm sure you know this already: If you put --stats on your rsync statement, it prints out a summary at the end which allows you to see the total size of the folder being synced, the total size of the files which had changed, and the total number of bytes needing transferring. It also gives you the difference between the last two, which is the number of bytes that were sufficiently unchanged, within the changed files, that those chunks did not need transferring.
The ratio of total file size: transferred data then gives a "speed-up" amount. 1 would indicate that 100% of the data needed transferring. On the legacy backup system, you'd get a speed-up of at least 3 on most dates when syncing the whole cpbackup folder, because the weekly and monthly directories would be unchanged. In practice I got much higher.
Since backing up the new files, I've been getting values like 1.02. It's only higher than 1 because I've included a few tarred configuration files of my own, and they won't have changed.
I'll experiment with the amount of compression, as you suggest. It may well be that a higher pigz number leads to a compressed file that cannot be treated sequentially, which would have this effect.