I don't have any reason to suspect rsync is the culprit for this slow speed.
I would suspect that the drive itself or its filesystem is the issue.
In fact, a few factors hint at a possible cause. You mention it's a USB drive, and you're transferring 150GB at once. I would hazard a guess that your USB drive uses Shingled Magnetic Recording (SMR).
SMR drives overlap the tracks in such a way that reading is done as normal, but every write to the drive, since it overwrites the neighbouring tracks as well, requires the drive to re-write a sizeable chunk of the drive, and the writing is slow. The miracle is that these drives perform as normal most of the time, because the drive remaps writes to a temporary holding area that doesn't use SMR, and then re-writes them to the drive later in the background. But this holding area is only a few GB in size, so for any continuous transfers longer than, say, 10GB, the write speed drops dramatically down to around 5MB/s. If you stop writing to the drive and let it idle for about 10 minutes, its performance will return to normal because it has had time to clear its temporary holding area, but will fall again if you do another multi-GB sized continuous write.
Despite some comments otherwise, rsync is nice and fast when operating locally, altering its setup accordingly. When operating locally, rsync uses no delta transfer. And, since compressing the transfer would make no sense when it's essentially just over a local pipe, I doubt the
-z has any effect, although the documentation doesn't say. Even if it does, it shouldn't be clamping the speed to <5MB/s, as its compression would be capable of many times that speed.
--inplace only affects rsync's behaviour when the file exists at the destination and only part of the file needs to be updated. Since delta transfer is disabled when rsync is operating locally, I believe it should have no effect.