I would expect that to happen only if you are using multiple threads / not waiting for submit-tx to return serially between each call

given indexing on the node is the biggest CPU + I/O bottleneck you are unlikely to get end-to-end throughput improvements by using parallelism on submit-tx (although it still might be useful if you need to reduce the length of time you keep the submitter worker process alive)

I can't see a good way to control the ordering of batches if you are running submit-tx in parallel (...unless you drop to using the ~internal submit-docs API and coordinate across the threads before "finishing" the txes with the write to the tx-log)