It would be nice to keep the blk*.dat files small as long as we can.
The eventual solution will be to not care how big it gets.
But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore.
There's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven't had time yet to add that option to the UI.
Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.
bumped and emphasis added.
Still relevant today.
Other quotes that are somewhat related:
Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
Note that when the 1MB limit was set, the average blocksize was like 2% of what it is now, they were still mining with laptops back then and they were apparently dealing with DOS attacks on the blockchain. A few months after the limit was put in place, satoshi still called bitcoin a "small beta project" and he intentionally wanted to keep it small (in userbase) because the network was not ready for widespread adoption yet.