Configuring your node with a mempool policy that rejects transactions that the vast majority of other nodes on the network are accepting will result in increased bandwidth usage and a longer block propagation time.

Blocks are usually relayed using compact blocks, which works by assuming that transactions that were in the mempool of one node were likely in the mempool of another node, so the relayed block does not actually need to send the entire transaction. The receiving node receives enough information to identify which transactions were in the block so it can reconstruct it on its own using the compact block data and the transactions in its mempool. However, if the mempool policies differ, then the receiving node has to ask the sending node for the transactions it does not have. This introduces extra round trips of communication, which increases the time it takes for the receiving node to have the block ready for validation. Therefore, block propagation is delayed. This can lead to an increase in the stale block rate.

Additionally, in order for these alternate mempool policies to work, your node has to receive the transaction in the first place in order to be able to determine whether it should reject it. It will receive the transaction, find it does not meet the configured policies, and then forget about the transaction. If that transaction is included in a block, then it's going to have to receive that transaction again. The result is that the transaction must be received multiple times and consuming extra bandwidth to do.