I'll try to answer that one: The benefits are mostly for the node runner himself: He gets better fee estimation, and can verify a mined block more quickly because he doesn't have to request the previously filtered TXs from the network. The sum of those benefits, applied over all nodes, increase the decentralization (better fee estimation), speed and reliability (fewer orphaned blocks) of the network as a whole. Which is part of why core wants it as a default. Another part of why core want it is, that their code base becomes clearer and smaller, making it less prone to bugs and cutting dev overhead. IMHO the split between core vs knots happens along the axis of "the right thing" vs "the possible thing". Knots side wants to fight spam because it's The Right Thing™ (I think they're right), core knows that's going to be a losing battle (I think they're right, too), which they will have to fight with their few resources, constantly updating filter rules and distributing them, in a non-centralizing way, against VC funded attackers. That's the gist of it.

This is the best explanation and aligns exactly with how i understand and view it. I do not disagree on running knots though i can't really say how much of a burden it would be on the network if we still have to toss around the blocks with 100kb OP_RETURNS in them after a block has been mined. I guess we'll have to see. Knots is the protest sign that gives a signal but can just be walked around and ignored.