Why should BIP157 compact filters be processed in-order? In BIP157, under &quot;Client Operation&quot;, we have the following paragraph:

Starting from the first block in the desired range, the client now MAY download the filters. The client SHOULD test that each filter links to its corresponding filter header and ban peers that send incorrect filters. The client MAY download multiple filters at once to increase throughput, though it SHOULD test the filters sequentially. [...]

I'm wondering about the bolded part: why should the client test the filters in sequence? Why can't it test them as it receives them? I'm having a hard time coming up with a good reason to test them sequentially. Anyone knows?
A HD wallet doesn’t know what indexes of a seed to scan for until the ones prior have been used, which can’t be discovered out of order. To allow for out of order scanning the address gap limit would need to be prohibitively large, and might still result in re-scanning filters if the wallet is particularly active.