This is deliberate, and in my opinion, desirable.  Same thing happens
when doing a check or any kind of rebuild on multiple arrays that use
partitions on shared underlying devices.  If you don't limit the raid
background activity, the extra seek load on the devices can severely cut
performance, especially on spinning rust.

If I was doing a 'normal' resync, I would also agree.

But my point was this...
My raid was doing a --replace of /dev/sdf1 with /dev/sde1
It was only reading/writing from/to those two devices, not the other
disks in the raid. (i.e. /dev/sd[a-d] were not being used)
The other job I started (dd if=/dev/zero of=/dev/sda2 bs=1M) was only
writing to /dev/sda

These jobs should be are perfectly capable of running in parallel
without slowing eachother down.

I think the logic that pauses a resync on 'related' disk activity
should treat a --replace slightly different