Agreed on both main points you made. Blacklisting would be near impossible to implement *and* it introduces a new validation criteria as IFP proposal would have had.
I know the IFP proposal seems to be losing support, but let's examine theoretically if BTC.top & others went ahead and set up their plan & code in ABC to pay to a HK fund address.
Now imagine BU sets up their code using BUIP143 as justification to soft-fork in a rule which orphans any blocks containing the "HK fund address(es)" advertised in ABC code.
If we want to keep a "tax free", non-discriminatory incentive structure on BCH, I'm not for such a blacklist, and I am contemplating putting up a counter-BUIP to express that.
One possible BU defense would be a further SF to restrict CB outputs to a address, but I'm sure you can see how that would be another bad move (think existing donations & optics).
I opened another BUIP, it would ask to release a May version that contains any non-controversial updates, but simply not include orphaning based on some involuntary CB payouts.
makes sense to make it explicit but to my eyes this come bundle w/ blacklisting. You basically introduce a precedent and remove plausible deniability when it will be most needed.