I’m not sure I follow this explanation, but the conclusion is correct. The approach wouldn’t work under a candidate header branch above the milestone (assume valid block) because blocks above the block being validated are updating prevout existence and spentness. So existence in the utxo store no longer represents order. Under milestone, validity of the branch is assumed so this doesn’t matter, the objective is just to populate the utxo store up to the milestone.
A material cost of this approach (under milestone) is that the utxo store must not only be thread safe, but locks must persist across each output being searched, compared and written. Given that there are billions of outputs this is a non-trivial consideration.
Ultimately this can be resolved by just downloading the full utxo set under assumption as well, which is already implemented.