I agree with your last post here. The thinking of most core developers is that there is no point in maintaining an option that effectively achieves nothing. It is compared with a placebo. If transactions make it into blocks anyway, and there is no physical resource consumption downside, what is the point of keeping them out of the mempool?
Discussion
Well I’m no expert but it seems to be that if ocean mines a block with a strict data limit, then on average it will drive big data transaction cost higher.
So yes it does matter imo.
Regardless, I am not in agreement that the current Bitcoin core software should remove the ability for users to set their own limit for op_return size
I think Ocean's market share is too small to have an effect here, though obviously that might change. They also use a different client already, so why should Bitcoin Core maintain something that they don't even directly use?
What does that even mean? 
I'm not sure what you are getting at here. Do you mind elaborating?
"They also use a different client already, so why should Bitcoin Core maintain something that they don't even directly use?" -?
Oh, I was under the impression Ocean uses Knots exclusively. But I guess it could be relevant for people who would like to relay transactions to Ocean, or a Datum template provider.
Should add that I actually do support keeping the option to limit relaying these transactions.
We are also arguing on stackernews. thanks for the discussion and consistency.
I say it's a political issue at this point. bitcoin-core must stop appearing to support the forthcoming "built on bitcoin" shitcoins.
see NVK's comments to Livera
The PR should be rewritten after public discussion at the big conference coming up.
I have a feeling it will be. I'm usually not a mempool developer outside of getting its logic isolated from the rest of the consensus code, but I do care about data embedding too. I wrote my diploma thesis on the very topic.