A "51% attack" means a bad guy getting as much computing power as the entire rest of the Bitcoin network combined, plus a little bit more. The Bitcoin wiki has a good summary of what a 51% attacker can and cannot do.

One of the things a 51% attacker can do is prevent any transactions or new blocks from anybody besides themselves from being accepted, effectively stopping all payments and shutting down the network.

That would be bad.

But it would also be obvious it was happening, and pretty easy to defend against. As I said on the Bitcoin Forums:

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 they'd pretty quickly run out of old, high-priority bitcoins and would be forced to either include other people's transactions or have their chain rejected.

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.

The devil is in the details, of course, and the risk of introducing a new chain-acceptance rule (high) have to be weighed against the chances that somebody rich and irrational will try to pull off the attack (low, in my opinion, but  maybe I'm not sufficiently paranoid about Big Banks or Big Government using Dirty Tricks to shut down Bitcoin). Maybe I'll code it up and keep it as a "Not To Be Used Except In Case of Emergency" branch.