Você esperaria que rsync fosse mais lento que cp para uma cópia primeira , porque faz um pouco mais de "to" ing e "fro". Talvez não demore 3 vezes mais tempo.
Você esperaria que rsync fosse mais lento nas cópias subsequentes de "atualização" se a opção -c fosse usada, e read-and-checksum fosse uma operação cara no máquina de destino (disco lento, ou CPU lenta ou memória insuficiente). Da mesma forma, pode ser lento sem -c se houver arquivos grandes e muitos deles forem alterados.
Se você esqueceu de usar -t nas execuções inicial e subseqüente, isso também faria com que o rsync tivesse que ler e verificar todo o arquivo.
Basicamente, sempre que o rsync tiver que escrever tudo (ou quase), o cp irá ganhar, então você deve ter o cuidado de configurar as opções para que ele possa fazer o mínimo de trabalho possível.
Se um rsync com arquivos completamente inalterados não completar no tempo que leva para "stat" todos os arquivos na árvore (no disco mais lento), então você fez algo errado.
Outros problemas com o uso do rsync em máquinas lentas são os custos indiretos de compactação e criptografia. Você deve desabilitar essas opções (ou torná-las compatíveis com o que você usa para cp) tanto no rsync quanto no SSH, tanto quanto possível. O SSH não desabilitará completamente a criptografia, é claro, mas você poderá ajustar as cifras em ~/.ssh/config
(na outra máquina); aqui está o que eu uso para minha Synology:
Host diskstation
Ciphers arcfour256
macs hmac-md5-96
onde "diskstation" é o endereço IP do seu NAS.