Perhaps it's also worth explicitly pointing out for people following at home how this proposal has a very real confiscation risk: bare multisigs can easily violate the proposed limit-- if uncompressed points are used an "of 8" policy is sufficient, otherwise I think 16 is needed but both are within the limit of 20 in checkmultisig. This is much worse than other confiscation concerns that have gummed up most (all?) other cleanup proposals, because rather than requiring some very contrived thing that probably no one would have ever done except as lols bare multisigs is a thing that has actually seen real use and could have been created by someone doing something completely boring... doubly so because the inadvertent P2SH script size limit may have explicitly pushed people into using bare CMS for a large policy when otherwise bare CMS is at least a little weird.
Aside, some of the confiscatory concerns could be greatly mitigated in proposals along these lines could be greatly mitigated if the rule was only applied to transactions which either have no post-activation active nLocktime or have at least one input with a post activation height. Such a move could also be done incrementally, limiting it for new coins and then after giving a longer period to unearth any confiscation risk applying it more generally if none arises. It still wouldn't completely eliminate a confiscation risk as there could be an unconfirmed *chain* of transactions, but perhaps a more limited rule would be easier to argue had an insignificant risk. Similarly, other such carveouts could be made for more likely script forms.
One even more conservative possibility would be to trace the "maximum reorg height" (MRH) of every output, which would be the height of the highest coinbase transaction in its casual history. If a transaction has any input with a MRH which is post-activation then it couldn't be part of an unconfirmed chain that predated the rule activation. The biggest downside is that implementations don't currently track this metric in their utxo set and doing so would add a few bytes to each utxo entry and a complete resync/reindex in order to enforce the rule. I believe this would essentially eliminate the confiscation risk.
I'd generally say I still think the proposal has little value relative to the inherent costs of any consensus rule change and potentially has an unacceptable confiscation risk-- MRH tracking might make that acceptable, but comes at a high cost which I think would clearly not be justified. OTOH, MRH tracking might also be attractive for other cleanup proposals having the similar confiscation risk issues and if so then its cost may be worthwhile.
I say it has little value because while keeping crap out of the UTXO set has extremely high value, anyone who wants to stuff crap in will just use multiple crappy outputs instead which is even worse than using a single big one especially given that >10k is already unspendable, prunable, and already pruned by implementations. Worse because each distinct output has overheads and because even non-op-return becomes prunable if its over 10k now, while a dozen 520 byte outputs wouldn't be prunable under this proposal. So, paradoxically this limit might increase the amount of non-prunable data. A variant that just made >520 unspendable would be better in this respect, but I doubt it would at all satisfy the proponents' motivations. Likewise, one that expanded the threshold to more like 1350 would at least avoid the bare CMS concerns but also would probably not satisfy the proposals proponents.