You could just run multiple rsync processes using different src and dest paths to achieve multiple copy streams. Anyway this would not be likely much faster if rsync is run over encrypted SSH due to CPU performance, compared to unencrypted SMB.
My guess is the actual bottleneck would be directory traversal and metadata stuff - i.e. trying to keep the pipe full, not saturation effects.
Yeah I know on src/dest. I've done this sort of approach countless times in various technologies in the past 40 or so years, but that always puts the mechanism for checking things in onus of the human rather than having that one command that does it all right.
Anyway, not a slight on rsync in the slightest - it doesn't have this probably because no-one realistically actually needs it most of the time.