This is just a feeling because you explained me that rclone has (really?) no better way to sync the whole tree than querying recursively (and concurrently) for folders content. Really there's not a single API to download the whole index starting from a location, with the server optimizing the transfer as much as possible (file names are highly compressible) and that is free of throttling by definition because the server also decides a paging strategy? Sure: this single API call can't be made parallel, but it seems to me a better strategy for me for this kind of unidirectional synchronizations. When the index is fully downloaded, then you can do any amount of needed transfers concurrently. This is just a speculation of mines: you (rclone devs) may already have decided this is not a good strategy because of how modern clouds work. But as a matter of fact I notice throttling also when syncing unchanged trees, where the amount of actual file data transfers is (and will be) 0 bytes.
Have you
• tried --fast-list?
This was one of the first tries I did and didn't seem to help me. Sorry, I haven't tried it more recently.
• traced the rclone communication with --dump bodies?
Sorry, no. Should I?
• experienced a sync tool that did the same, but faster?
When syncing some large whole tree accounts from scratch with the official OneDrive client in the company don't seems to hang the way rclone did for me, but I can't inspect them the same way, so I can't say for true.
This may help. Reducing dynamically (and gradually) the concurrent transfers to as low as 1 (no concurrent transfers) as a result of being throttled may be a key requirement in surviving some aggressive OneDrive throttling policies.