You are asking the obvious questions, and that there don't seem to be super-compelling answers should set off alarm bells. Of course, the real answer is that OP_RETURN limits in fact DO hinder spam. For the parent post to claim that "node operators setting a lower limit...do so at their detriment" is incredibly myopic and imo misleading. In fact, when viewed in the context of a spam transaction, the node being forced to redownload the transaction after it has been added to a block, is an anti-spam FEATURE, not a bug (see below).
I invite you to check out this post here (which is pro-Knots):
You are asking the obvious questions, and that there don't seem to be super-compelling answers should set off alarm bells. Of course, the real answer is that OP_RETURN limits in fact DO hinder spam. For the parent post to claim that "node operators setting a lower limit...do so at their detriment" is incredibly myopic and imo misleading. In fact, when viewed in the context of a spam transaction, the node being forced to redownload the transaction after it has been added to a block, is an anti-spam FEATURE, not a bug (see below).
I invite you to check out this post here (which is pro-Knots):
view on x.comas well as the parent (which is pro-Core):
view on x.comand the followup (which is again pro-Knots):
view on x.comIf you have difficulty following the logic, I think this presentation (which is pro-Core), does a good job of explaining the big picture:
view on x.comAnd you can read the response (which is pro-Knots):
view on x.com