Segwit eliminates the size limit and replaces it with a weight limit. The weight is computed so non-witness data (e.g. the above outputs) count 4x as much towards the limit as witness data (signatures). The fixes the incentives by balancing the costs of signatures vs outputs to be roughly equal.
The problem is 4MB weight is arbitrary number which only roughly reflect exact ratio for optimally balancing the costs of signatures vs outputs. Around 6MB weight (ratio to 1:5) should be more optimal, no? Exactly (29+141)/29 MB weight, if Luke-Jr is right at:
https://github.com/btc1/bitcoin/pull/11Non-witness data creates the need to produce witness data in the future to verify it. Currently a 1 MB block can create UTXOs such that it requires four 1 MB blocks to clean it up! This is why it is logical to weigh witness data (which cleans UTXOs out) at 1/4 the size of non-witness data (which creates UTXOs that must later be cleaned up). It balances the creation with the cleaning: 80 weight units for each.
BTW, ratio to 1:4 does not equeal to 1/4, so it would be more logical to have 5MB weight instead in the quote above...
Thinking on this topic tonight, it occurred to me that spending actually uses not just the 72 bytes of signature, but also the pubkey size, and the input txid and index: a total of 141 bytes. On the creation side, there is also the amount, so about 29 bytes. This is a 5:1 ratio. An alternative to simply increasing the weight limit might be to apply the discount also to the input txid and index and/or adjusting the weight ratio to 1:5.