This has been clear to me for as long as I've been busy with WikiTree Anne. Only issue is your last statement, to identity the final WikiTree ID before doing any mergers which is either a) simply impossible at times b) or impractical c) extremely time consuming and confusing. Remembering that this period (1600'-1750) I'm dealing with has at times 10 different variations of the same LNAB (and therefore duplicates) in different languages that differ from family member to family member and generation to generation.
At times indeed it is the case that as luck would have it I'd also have the (nearest to correct) LNAB protected within this project already by then. However many times this situation (a chosen, validated profile or choice for such a profile) has not been made yet. Simply because all the duplicates are still being identified, and cross-generational mix-ups and other issues being resolved. That's why merging duplicates allows for the collation of data wich in turns allows for a better and more accurate picture which in turns facilitates the research and the validation of the profiles. We mostly do not even know what the final LNAB until all the merging and collation of the variants have taken place.
This process is not in sync with a situation of simply already having the correct spelling at hand. The latter is mostly the end result of research by members of the team solely working to validate LNsAB and cite and source them properly.
Only then a weighed decision can be made.