The strength of that argument depends on what "easier" means.

In my opinion, the argument becomes strong if "easier" means "less costful for the nodes", not "easier for the data publishers". This is the case if you use OP_RETURN instead of the more costly "fake public keys" method known by NFT platforms like Bitcoin Stamps.

Reducing the costs for node operators should be paramount, because the lower that cost, the higher the degree of possible decentralization of the network.

Or to re-phrase it: if you can't avoid data storage, try data publishers to use the least harmful way for the nodes.

For all other points @achow101 has already provided an excellent answer.

As I posted in another related threads, I have however some reservations against the "total liberation" of the OP_RETURN limit in one single step. It is the easiest way to make that move and it seems to have been already decided, but as this discussion was very politized and generated a lot of drama, I am worried of some potential "revenge attack" once Core 30 gets published. A (standardness) limit to a single OP_RETURN of 512 or 1024 bytes and lifting in further versions would limit the potential of these possible attacks, without harming the "commitment" use case (of course: if somebody wants to attack, he can simply pay the miners, just like now). But of course as datacarriersize is still there every node can decide to set it to a value in that range.