Is there any point in passphrase-protecting an SSH private key that is used by a service account?

In these sorts of scenarios, I leave the private key unencrypted (except maybe sitting on a disk that is encrypted), with read permissions restricted to root and the cronjob run as root, but do my best to restrict the usefulness of this key to the very specific task (versus allowing it to login to the remote machine with full access).

This can be done fairly straightforward by configuring ~/.ssh/authorized_keys to automatically run a specific command when logged in using the specific key.

command="/usr/bin/remote_commands_to_run.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3Nz...DfE= root@some_client

See this answer for more. You should be careful that the commands in /usr/bin/remote_commands_to_run.sh do not allow an attacker to escape to a shell. It may also make sense to create a limited account on the remote machine with say a shell of /bin/false that runs the remote command (e.g., put the public key associated with the private key in that limited user's authorized_keys).

As always after setting it up, try and test to make sure the key doesn't have more privileges than you expect (e.g., that sftp doesn't work, that rsync doesn't work, etc).

On further notice, I see your particular task is to rsync data (presumably in specific directories). This is probably doable with limited accounts (e.g., chroot'd to only be able to see those specific directories with no access to a shell). I believe tools like rssh can be used to do this; consult superuser or serverfault for best advice.

Granted what I do in this scenario is mount the specific directories as a network drive (e.g., through NFS / sshfs) and then do the rsync to that mounted directory in a cron script.