If a miner includes OP_SUCCESS spends, they may include a transaction that is invalid according to a future soft fork they are not aware of. In this case they would create an invalid block, and other unupgraded miners may build on top even though they themselves do not include OP_SUCCESS spends in their blocks.
So that would be miners essentially enforcing proposed soft forks by standardness. That’s a different thing from just mining all valid transactions, and i think presents at least three types of challenges:
- scaling: which proposals should a mining pool implement? When should it stop enforcing each? How closely should it monitor progress on each (see next point)?
- DoS risks to the miners and the network: what if a proposal is updated? Any change in semantics can be exploited as per the above.
- incentive: once you open the pandora box, why would a miner collect fees only for transactions that respect the proposal? They are all consensus valid anyways and would not lead to its blocks being rejected.
Right, any miner.
I’d rather not find out. 
I don’t think your isolated instance is really disruptive. But we’ve seen in recent years that it’s easy to kickstart a trend to disrespect widely-enforced standardness rules on the network. That has the potential of becoming disruptive very quickly. And as much as i didn’t care too much about having to increase the size of standard OP_RETURNs or decreasing the minimum relay feerate, i would very much like that we be able to rely on upgrade hooks for at least a little longer.