I think in the event of a 51% attack, trusted people, miners, mining pools, businesses with a big stake in bitcoin, and other entities will start signing blocks to say that they have received them and believe they are legitimate (i.e. not attack) blocks. Clients will evolve so that the signatures of trusted people will be considered as weight towards block validation.
This would be some sort of centralization that is hard-coded into the clients - certain market participants (those owning these "trusted" keys acc. to client source code) would have a stronger weight by the power of client source code.
I think, if we have a protocol change, then the other protocol change (namely having the difficulty threshold a function of the stake (a second term, on top of today's formula)) would serve a similar purpose, but without pre-compiled centralization. So I would prefer such change, and only if this fails again, i.e. if the former 51% attacker still continues and also accumulates enough stake so that he can again attack the network successfully, then I would consider the above mentioned solution as a last resort.
In the interim before that happens, you'll also have trustworthy entities offering an emergency solution: "We'll filter out the attack blocks if you connect to us... bitcoind -connect=xxx.xxx.xxx.xxx". It'll be temporary centralization of the network.
In the long run, a 51% attack won't succeed. A system that uses a combination of proof-of-work as primary, human consensus for fork resolution as secondary, will raise the bar from 51% all the way up to 99%. That's about as democratic as it gets.
Exactly, and this thread is just about how this "human consensus for fork resolution" (i.e. modest adaptation of the bitcoin protocol) may look like in practice (should it ever become necessary).