Generally, a configuration option should be provided when one can provide recommendations when the configuration option should be used and how it should be adjusted. Historically, it looks like the vast majority of Bitcoin Core nodes use the default configuration. When at least about 10% of nodes accept a transaction, it propagates somewhat reliably to all nodes in the network that accept them.

This means that if the default configuration for the OP_RETURN limit were raised or removed altogether, such transactions would soon after the release reliably propagate and, perhaps a little later, also get mined by a larger proportion of the block authors. Node operators setting a lower limit would do so at their detriment: they would download the transactions after an announcement from their peers, reject adding it to their mempool, then download the same transactions again when a block includes them, incurring increased bandwidth and extra latency on the updating to the latest chain tip.

Some proponents of the increased limit argue that the configuration option should not have been added in the first place, as it is ineffective to locally configure a different limit, and that the configuration option is even less useful after dropping the limit. Other contributors argue that setting a lower limit only harms the node operator, and removing the configuration option takes away control needlessly.