Either the implementation does nothing during IBD, in which case it saves nothing there.  Or during IBD for every output created it consults some hashtable of bad outputs to determine if the output should be skipped in which case the proposal would likely *slow* IBD by doing a lookup against a giant table with about half as many entries as the current utxo set for each utxo created and require that this big table of excluded items be kept around at least until its snapshot point.  

I see. So now that UTXO bloat was used as an excuse to implement core 30 and blow up the op_return limit, we are now back to pretending UTXO bloat is not a problem?

Here is how I imagine it will happen.
A few years from now, after you tell me a zillion times that nothing is happening, and most nodes have downgraded to spamware 30, and you will have come out as triumphan against us, the parranoid anti-spam knotzis.

A shit ton of illicit, disgusting material will be posted on chain. With op_return blown up, they won't have to break up their shit into a 100 different transactions and have to ask Mara's spamware SlipStream for permission.