I find it curious that Mike Hearn pins some of his rant on troubles with ProHashing. While I support the pool - and mine there quite often (exclusively for much of last year) - their pool represents a pin-■■■■■ of hash rate and virtually nothing as far as Bitcoin transactions are concerned. Yes, they are a USER of Bitcoin and have a stake, however small, but to use the Sokolowski's pool as an example of a user that is having trouble sending funds for low fees because their business plan dictates they must (otherwise that guy with a 500KH scrypt miner can't get his satoshi dust everyday) is a straw man argument. If the business plan doesn't work that business will fail - simple as that. Satoshi failed to mention in the white paper making certain people sending fractions of a penny covered and ensuring a timely delivery of said dust. Yes, one of the benefits is that Bitcoin CAN accomplish this, not that it MUST. This is why from the dawn of mining pools, almost every single one has a defined minimum payout to ensure that the amount sent makes sense given a standard delivery fee. Don't like that? Don't mine at pools that don't fit your philosophy. I have more to say but I'm on my mobile at the moment.
EDIT - OK back at a real keyboard.
If I pay UPS $2 to ship a 50lb package, do they give me a guaranteed delivery date? If I don't insure the package, do they pay me in full for the value of the contents if they lose it or it otherwise fails to be delivered? The answer to these questions is no and no. If I, instead, pay UPS $50 to ship this package do they guarantee delivery? If some of that $50 is used for insurance do they pay me back if they lose or damage it? The answer to these is yes, and (likely) yes. You have to 'pay the freight' if you want to be sure the proper care and expedience is utilized in your delivery.
How much do I pay? Those fees are dictated by what the market will allow. Same as with Bitcoin. If the network is flogged with transactions and you are in a hurry to see the funds confirm, you extend the fee a bit to make sure the pools and miners get on it quickly. Most wallets now have a button to allow for priority on the network - it's just a question of whether you'd rather use it and pay for the enhanced service or complain that you can't get a transaction to occur for free anymore. Again, it's about what the market will allow. Bitcoin has it's roots in libertarianism - free trade should not be a hard concept for people to understand.
The upshot is that the network SEEKS to accommodate everyone, no matter whether they pay $2 or $50 which is a fine thing and very noble. If the network cannot scale to handle the $2 and $50 customers, what's to be done about that? Nothing? If nothing is done, the $2 remittance takes a long time to process, if it ever does. Is that OK? Well, if you follow the slippery slope, not really - since there could be an ever-increasing fees for transactions to process... to a point. Once the value a person gets for using bitcoin to transact is exceeded by the cost of doing so, that person will seek the next best method of transacting, be that fiat or another acceptable form of transferrence. So this is where the crisis really lay - ever increasing numbers of people are choosing Bitcoin to transact with, but the fees to do so quickly and easily are rising - it no longer is really a zero-or-low fee method and one of it's main features becomes a 'bug'.
Look - the network isn't always flooded with memcache transactions. There are plenty of times during a day or week when it's less utilized than other times. Why isn't there a feature in the wallet that accommodates scheduling payments for times when the fees are suitable to a certain transaction being pushed to the network for processing? The historical data is there to be relied on. Why can't the wallet(s) be programmed to suggest times when a zero fee transaction might best be handled quickly? Why can't that kind of efficiency and intelligence be built into the wallet TODAY without having to resort to forks (and pitchfolks)? These guys (the developers) think they have all the answers - but the efficiencies and optimization of the available resources have yet to be tapped. What about a scale in the wallet itself that reads the historical data from the last 144 hours and looks at the memcache and shows the user how much it would cost for a transaction delivery in 60 minutes versus 24 hours? There are lots of other options, but I believe the developers are, perhaps, too close to the fire - or are too prideful to believe others can make meaningful suggestions on how to solve this problem.
Butthurt ensues. Mike Hearn proposes a solution which doesn't fit everyone's way of thinking. He get's upset that people don't agree with him.
Then the banks come knocking on his door... conspiracy theorists unite in condemnation using pitchforks and torches.