Your solution is indeed simple. But it doesn't do the same job that checkpoints do. Checkpoints are not about forks in the present or future, they are about helping clients avoid dead end forks in the past, while they are doing their initial sync. Checkpoints help new nodes catch up to the network with minimal annoyance for the node operator, nothing more*.
So you are saying that checkpoints don't actually prevent my node from downloading, storing and routing an
alternative block that would refer to the genesis?
Or are you saying that they do prevent it, but the important thing here is that I should care more about those who are just downloading the chain and dont know yet which branch to choose?
Well, the genesis hash was coded in from day one. If you want an alternate chain, you need a new genesis hash, plus you'd have to clear out the checkpoints. (My apologies if that wasn't what you meant, I'm not entirely sure that I understand you.)
The early blocks had very low difficulty. If I wanted to, I could generate thousands of low difficulty blocks, with appropriate fake timestamps, and I could set my node to wait for new connections, then feed those bogus blocks to the noob. They'd figure it out eventually, but I could keep them mired down for hours or days, working on my garbage. The checkpoints give a handy shortcut to that "eventually". If my chain doesn't include the checkpoint blocks, the new node won't waste their time on it.
The notion of "the correct chain" gets fuzzy. If I have a lot of hashing power, like more than the rest of the world, and I start today making a new chain, but I keep my farm isolated from the rest of the network, is it "the correct chain"? The only really hard rule is that the longer (more work, not necessarily more blocks) chain is correct. My chain would be (work) longer, so in that sense, it is correct. But no one knows about it but me, so the world would be working on a chain that they think is correct.
When I release my chain, it will overturn possibly thousands of blocks, possibly millions of transactions. The hard rule says that it should happen, but almost no one would actually
wants that outcome. A checkpoint
could invalidate my whole chain, if a big part of the network upgrades to a client that includes a checkpoint that happens to come after I started.
That situation is unrealistic, intentionally. But it shows that the simple rule that we can easily write into our software is incomplete. We humans want the rule to be "the longer chain is correct, except...", and the "except" part is hard to write. We know that checkpoints aren't the right way to codify the exception. If you've ever talked to Gavin, or even read his posts on the subject, you'll know that he absolutely
hates that he could end up in the position of picking which chain wins.
So, we end up in the strange situation we are in. The checkpoints are useful in the real world , but we can see that they also hold a power that no one actually wants to wield. The devs advance them now and then, but always sorta grudgingly, and always months behind. If someone released a 5000 block attack chain, we'd all be bitching that the checkpoint was too far behind. Because no one has (and probably never will) hide a fork of that length, we are all bitching that checkpoints are contrary to the bitcoin design.