http://gavintech.blogspot.com/2012/05/neutralizing-51-attack.html?m=1Gavin: "The code already has a notion of (bitcoin priority) that it uses to prevent transaction spam (sending gazillions of tiny transactions to yourself, just to make everybody else do the work of validating and storing them); extending that to influence the chain-fork-selection code wouldn't be hard....something like....ignore a longer chain orphaning the current best chain if the sum(priorities of transactions included in new chain) is much less than sum(priorities of transactions in the part of the current best chain that would be orphaned) would mean a 51% attacker would have to have both lots of hashing power AND lots of old, high-priority bitcoins to keep up a transaction-denial-of-service attack. And theyd pretty quickly run out of old, high-priority bitcoins and would be forced to either include other peoples transactions or have their chain rejected".
In Andresens post, he notes that such a solution would be Not To Be Used Except In Case of Emergency.
As btchris says, it just prevents a specific kind of attack, not all 51% attacks.
For me, 51% attack is both the basis and the weakness of Bitcoin. The hashing power is the projection of people's wealth outside of Bitcoin, it's important for the hashing power to be in proportion to the wealth they have if you want them to accept Bitcoin.