The protocol requires that freshly generated coins wait 100 blocks before they can be spent in order to avoid polluting bitcoin addresses with bitcoins that are "uncreated" by a reorg that invalidates the block that created them.
If we decide that "the chain with the most difficulty" means "the chain with the most difficulty over the last N blocks" and pick a good N, it could make some things simpler AND make transactions at a depth of at least N immune to a 51% attack. Thus, it limits the value of cornering the market in hashing power. Such "cornering" could happen without being noticed, so it has begun to worry me.
If I remember correctly, we've already done this by (sometimes?) making checkpoints in the Satoshi client at sufficiently large depths when new clients got compiled.
N = 4032 would ensure that two difficulty levels are spanned.
N = 100 would change the pain of a 100-block reorg from something barely tolerable to something impossible.
If the protocol were changed to use this, then a UTXO database based on the results of the blockchain up to the checkpoint block could replace the gigabytes of blockchain that we currently use for validation.
EDIT: Why I asked: It would be nice to validate a UTXO database so that one didn't have to build it from (always increasing GBs of) downloaded block data. We validate transactions before passing them on, but do we validate them when we download a(n old enough) block? I think we trust that whatever (old enough) block we get from a peer contains good transactions, so we don't hunt all previous blocks to validate them. If this trust is already being used, as I suspect, perhaps it is more useful than we know. I asked a related question: Would a normalized, hashed, protected chainstate reduce miner storage costs?. I'll have to explore the work on making a UTXO Merkle tree as that seems promising.