One thing that seems to have been forgotten is that the 1MB block size does not represent any particular rigorous design choice; it is purely arbitrary.
It does not represent any type of technical sweet-spot; it neither falls under any reasonable MTU to prevent TCP fragmentation, nor does it guarantee in any unique way ease of transmission or lower latency. Chinese mining pool operators, noted as one of the more constrained stakeholders in this decision, have indicated that 8MB is a reasonable compromise in their situation. Unless individuals with specific, concrete use cases come forward with exactly how they will be marginalized by blocks in the 1-8MB range, we should consider 8MB the minimum applicable size for technical objections to raising the block size from a network propagation point of view.
It also does not represent any kind of economic sweet spot. If we accept the arguments on the mailing list that economic incentives for the creation of the fee market depend entirely on a single variable, the scarcity of space for transactions in a block, we should be talking about _decreasing_ the block size. In reality, this is clearly laughable. The real economic analysis would consist of a balance between the space for transactions in a block, the number of transactions being attempted at any given time, and the block subsidy, among many other factors. Viewing it in this light, the chance that 1MB by some divine miracle is the perfect balance of those economic considerations becomes exceedingly small.
(Personally, I believe that increasing the block size has a greater chance of creating a fee market after coinbase subsidies decline, as having competition for space in a block depends not only on the number of transactions that fit in the block, but also the number of people attempting to spend; if success rates fall dramatically, significantly fewer people will attempt to transact bitcoin. However, this is a discussion for another post).
If we stop considering 1MB to be some magic number, perhaps we can enter into a real discussion about finding what the right sweet spot is. We very well may decide that 1MB is _too big_; what should not be acceptable is conflating pressures to decrease the block size with reasons for inaction altogether. The end game of this debate should be to decide the new block size that balances, within reason, the various pressures in every direction.