I think you are right about consensus ship having sailed, but when it comes to mempool filters, that's not consensus breaking and I don't think anyone is suggesting anything that would be. If they are, I wouldn't support that.

If I understand correctly, the current debate isn't about inscriptions, which primarily use the witness data section of the transaction, making them difficult to differentiate from standard transactions. That is what Taproot enabled and it's debatable what can be done about it now.

As an aside, though, I don't think it is valid to say "Well the consensus was that we wanted Taproot, and the time to stop it was before activation." For consensus to be a valid argument for not doing anything at this point requires that those who supported Taproot activation all were aware that it would enable inscriptions. Otherwise, there definitely was consensus about enabling Taproot, as far as people understood what it would give them, but there definitely was NOT consensus about enabling inscriptions. That can accurately be classified as an unintended use-case of Taproot's features by using an exploit to disguise arbitrary data as part of the transaction's witness section, which no one realized would be the case at the time of activation. That would make it a valid endeavor to patch, if consensus supports activating a proposed patch, in my opinion.

Regarding the datacarrier limit for OP_RETURN, though, that has nothing to do with Taproot. That limit has been in place for years and years. Knots is not the implementation making "a retroactive restriction" on that particular front. Rather, it is Core that is now REMOVING the long-standing datacarrier limit, which was also previously configurable by node runners, but they are removing the option for node runners to set it according to their preferences. That makes the OP_RETURN limit much more akin to the block-size limit, though the change isn't consensus breaking.