You don't need OP_RETURN to store data, particularly hashes. The idea being it was to encourage people to store data in the least harmful way possible in outputs that can be obviously pruned; like it or not putting data in the blockchain is useful so people will do it, and there's no good way to stop people from doing so.
As you pointed out in a recent post*, P2SH^2 on the scriptPubKey side and MASTs on the scriptSig side would work to keep the blockchain from becoming a garbage dump. Since both of these changes would be very good for both scalability
and privacy, I don't understand why you were so quick to write them off as unlikely.
Of course, once data is prunable, it's no different than any other transaction in terms of impact on the system - you're still paying fees on the exact same basis as doing any other transaction.
The problem is that non-Bitcoin applications compete for scarce block space, driving up the cost of transactions for Bitcoin users. As you know, this cost is either felt in the form of fees, or increased centralization if the block size is simply raised to accommodate. I don't think it's unreasonable to say that Bitcoin users ought not be burdened by arbitrary demands of its blockchain.
You mentioned it being better to just focus on the root of the problem - fundamental scalability - but the potential solutions I've seen proposed by you seem like very radical changes (far more so than P2SH^2 or MASTs), and the conservative approach appears to be to protect the blockchain from abuse to the greatest extent possible
at least until a particular scalability upgrade has been 1) implemented, 2) well-tested, and 3) widely agreed upon.Regarding OP_RETURN though, I agree that it's the proper way of doing damage control (though I worry that it sends the wrong signal to users that this usage is acceptable, and not abusive, and will encourage more of it), but only while P2SH^2 and MASTs are not yet implemented.
*
My advice for new projects is to support multiple encoding methods, the same was Mastercoin did, so you aren't dependent on the Bitcoin devs. Incidentally there's no practical way to stop all those methods - even P2SH^2, itself a very invasive change to the ecosystem which is unlikely to happen, can't stop encoding data in P2SH scriptSigs without merkleized abstract syntax tree support and risky changes to the scripting language... and that in turn has the big risk that you make upgrades in the future, perhaps because a crypto algorithm has been weakened, much more difficult to implement.
Of course, that's why I'm spending my time working on actually improving fundamental scalability rather than wasting time trying to tell people what to do with a trust-free decentralized system...