I don't know why but the spinning disk is being crushed.

if you divide the mb/sec  by the reads you get around 4k per read
(that is about as bad as you could do).
if you multiply the reads/sec * r_await you get all of the time accounted for.

And since each read is taking around 8-10ms (around the disks seek
time for a new track) then each block being read is not being cached
in the disk hence probably not on the same track that the disk just
read or as the disk recently read and still has in its cache.  If the
file you are rsyncing was written slowly  or quickly with a number of
other IO's happening between each io then that increases the chances
of the file being massively fragmented and act like this.

Is this a single file and this single rsync is the only thing running?

And what disk are you syncing to/from?    And how was the file that
you are rsyncing created?    I have seen a DB do this (in a sequential
backup) and that file was created in such a way that for the most part
no 2 blocks were next to each other on a disk.   I believe the average
blocksize for that file was 5.1k.   the filefrag command will show
file fragments on some filesystems.  There may be different commands
needed depending on what filesystem the file comes from.