First of all, there is no "The mempool". Every full node has an individual mempool, and as these contain no transactions that are already in blocks (confirmed transactions), by definition nodes cannot be guaranteed to have agreement about it. So, what you're looking at it blockchain.info's mempool, which may or may not be similar to that of other nodes.
What can cause differences between mempools? One obvious example is in the case of a double spend: no conflicting transactions are allowed in it, so if two distinct transactions which spend the same inputs are broadcast into different places of the network, some will accept one, others will accept the other, based on which they hear first. That's not the only difference, though. Nodes can also have different mempool acceptance policies.
A node's mempool is ultimately its expectation for what transactions may reasonably confirm in the short to medium term. Good mempool acceptance policies are trying to model that expectation. If a transaction's fee is very low, it may not be worth keeping around if there are plenty of higher fee transactions to mine first.
And that is the basis for the mempool DoS protection that was added in Bitcoin Core 0.12. Roughly, whenever the mempool's memory usage goes over a certain preconfigured size (the
-maxmempool setting), we kick out the transactions with the lowest feerate, and (temporarily) increase the minimum feerate to get in in the future to that of the evicted ones. That solves the issue of unbounded memory usage.
But what about bandwidth? Things like BIP125 and this eviction described above essentially result in the ability to keep broadcasting transactions, and have them be accepted and replace other transactions, without really paying anything. I say paying here, because the fundamental rule we base mempool policy decisions on is that since we expect transactions in the mempool to confirm, and thus pay their fee. Thus, we'd want a rule that whenever something is evicted from the mempool (for whatever other reason than it confirming), something else pays "something" for that relay. In practice this is accomplished by having a separately configured relay feerate (which does not change when the mempool is full), that specifies the "price" for relay. In the case of mempool eviction, the new transaction(s) must pay at least that relay fee more than the fee of the replaced ones.