I don't think it makes sense, but I've heard Steve Lee make a similar argument about defaults around some of the quadratic hashing type transactions. That there need to be defaults that don't accept such transactions so that miners won't build blocks with them.

You may be thinking of the new policy Bitcoin Core v30 introduced to restrict the number of signature operations permitted in legacy script. The idea here is to discourage at the policy level in advance of BIP54 introducing a consensus rule that elevates the same limit to a consensus rule.

I think what Murch wrote here is exactly the reason why "the defaults are hugely important" is only relevant if (a) the defaults are enforced (spoiler: they are not) or (b) you are looking to restrict:

just a small minority adopting a more permissive behavior de facto establishes the policy. Similarly a small minority rejecting or lagging behind in the adoption of a more restrictive policy de facto vetoes it.

Note the direction: the more permissive relay policy always wins (as long as there's a miner with an as permissive inclusion policy.) This means that policy is largely meaningless in the presence of a desire to make it more permissive. It also means that policy doesn't work for introducing restrictions. At most: discourage.

The most important thing is that policy is a feature of software, not protocol. Either it's configurable/adjustable from the default (preferable) or one can just have a patch / alt client. Not to influence what gets mined, but what your own node relays / includes in block templates.

Is there any case nowadays to be made for uniform mempool that does not come from a telling-other-people-what-to-do philosophy? If not, then the only important thing is that you can do whatever the fuck you want.