And please, don't even pull the "price doesn't matter" bullshit lol.  Bitcoin is a currency, if one of your main development goals isn't to increase it's network effect and value, then you're probably doing it wrong.  A currency is a consensus mechanism between individuals in lieu of barter.  In order to fulfill that goal, the largest number of people possible have to be holders or it's either harder for them to do business, or they can't do business at all.  This means sane Bitcoin development has to constantly be trying to expand capacity to fit more users.  Unless capacity is already high enough for world reserve currency, any stagnation of capacity increase while users are demanding more will be viewed negatively by the market.

There's also no such thing as "spam".  If you think spam exists, it means minimum transaction fee is not set high enough.  Zero fee transactions should not exist in the first place.

Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments.

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.

I am not claiming that the network is impervious to DoS attack.  I think most P2P networks can be DoS attacked in numerous ways.  (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee.  0.1.5 actually had an option to set that, but I took it out to reduce confusion.  Free transactions are nice and we can keep it that way if people don't abuse them.

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.