It's an algorithm: total number of bytes divided by total amount of time. 

  That's total number of bytes to tape and the time data is the job run time. 

  Encryption and compression reduce the job rate because they increase the run time of the job.

  If you've spent time pondering it while jobs are running, you will have noticed how  the job rate increases on big flat files and decreases when backing up lots of tiny files.  The structure and density of the data being backed up is a big influence on the throughput  (job rate). 

Backups will always run slower on small files, as it reads each header of the file. This means the tape drive doesn't run at a constant speed.
Which is why flat file/DB backups are so much quicker...the tape drive streams the data as quickly as it can take it.

I have to disagree that encryption and compression always reduces job rate.  I tested a job which copied a 50 GB SQL DB backup file to an LTO1 tape.  With no compression and encryption I acheived a job rate 60% slower than if I had used software or hardware compression.  In this particular instance, I'm theorizing that the SCSI bus to the drive was saturated, causing the bottleneck.  Compression allowed the job to run faster to tape as there was less data on the bus.  The tape drive has it's own HBA on this particular server.

Sorry - you're right.  Encryption will slow the backup, but depending on your network environment and whether the backup is of local drives or not, compressing the data before sending it over the wire to the backup tape/drive will speed up the throughput (job rate).