It's nonconstructive nonsense to say the protocol shouldn't be used because the solution isn't as elegant as the dev's think it could be. I think Xnova has already responded on this point adequately.
The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *
actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (
https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.