Many, if not most, Bitcoin nodes offer transaction relay as a service to the rest of the network. If you broadcast your transactions to your peers on the network, they will forward them on to their peers, and so on. Because the peering logic deciding which nodes to peer with maintains wide connectivity, this service allows transactions to propagate across the network very quickly, and specifically allows them to propagate to all mining nodes.

Another service is block relay, propagating valid blocks as they are found in the same manner. This has been highly optimized over the years, to the point where most of the time an entire block is never actually relayed, just a shorthand “sketch” of the blockheader and the transactions included in it so you can reconstruct them from your own mempool. In other words, optimizations in block relay depend on a transaction relay functioning properly and propagating all valid and likely to be mined transactions.

When nodes do not have transactions in a block already in their mempool, they must request them from neighboring nodes, taking more time to validate the block in the process. They also explicitly forward those transactions along with the block sketch to other peers in case they are missing them, wasting bandwidth. The more nodes filtering transactions they classify as spam, the longer it takes blocks including those filtered transactions to propagate across the network.

Transaction filtering actively seeks to disrupt both of these services, in the case of transaction relay failing miserably to prevent them from propagating to miners, and in the case of block propagation having a marginal but noticeable performance degradation the more nodes on the network are filtering transactions.

These node policies have the explicit purpose of degrading the network service of propagating transactions to miners and the rest of the network, and view the degradation of block propagation as a penalty to miners who choose to include valid transactions they are filtering. They seek to create a degradation of service as a goal, and view the degradation of another service resulting from that attempt as a positive.

This actually is a DoS attack, in that it actually is degrading a network service contrary to the design of the system.