The consensus tends to be,
- It bloats the chain
- It incentivizes non-currency chain usage, which negatively impacts all who use bitcoin as a currency
- It is unavoidable...
- ...so we might as well figure out a way to permit a few tiny uses, such as carrying a hash or auxiliary transaction id or comment along with each transaction, while creating some limits that discourage wholesale binary data storage in the main chain.
This is a poor idea currently because only /actual developed/ demand for it are things like instant messaging, transaction source deanonymization, and timestamping— things which are would be done better without creating an immortal burden on all future users of Bitcoin by instead using payment protcols or an overlay messaging network (or both) (or in the case of timestamping O(1) cost for infinite use by doing it via the coinbase). The applications where it would make sense are few, speculative, and perhaps won't ever be developed much less used.
It's not like its impossible to write non-standard txn now, you just have to get a miner to mine them— so please, if I'm mistaken point me to the virtuous usage of OP_DROP in the chain. Additions to the standard set should be based on established trial usage, not speculation.
As far as mitigation goes, if you were to propose that they only be standard in scriptsigs (allowing fast pruning) or P2SH, that they have a maximum of 32 bytes (as you did), and that SHA256(data) begins with 32 zero bits, and that they have a fee which is >= the mean in the last N blocks, you'd probably cut it down to harmlessness... because you would have successfully taken it away from most of the applications where it doesn't belong (except timestamping, which is probably the least bad especially if limited to scriptsigs), but I think that would be pointless because doing so also only leaves it for applications which are currently undemanded and non-existant.
