You are correct that any client which sees two different forks can easily determine which one is longer. But consider the following possibilities:
The node might never see the longer fork. This can happen in case of a Sibyl attack, where the attacker has control over the victim's Internet connection and arranges that the victim only connects to evil nodes. These evil nodes will only send blocks that are part of the shorter, malicious fork, and the victim will assume that this fork is the "real" chain because there is nothing else to compare it to. So the victim will believe the attacker's view of the transaction record, at least until they manage to get connected to an honest node. Checkpoints ensure that such an attacker can only manipulate the victim's view of history as far back as the latest checkpoint, which at least puts some limit on the damage that can be caused.
The longer fork might be the "evil" one. This could happen in the case of a 51% attack, where an attacker who controls more hashing power than the rest of the network decides to fork the chain and "rewrite history" from some point in the past. With their hash power majority, they can eventually make their fork longer than the "real" one. A checkpoint ensures that they can only rewrite as far back as the checkpoint.
In each case, this is a rather minimal restriction on the attack; the ability to rewrite history back to the last checkpoint is still devastating. But it might help in reducing the chaos until the victim can connect to an honest node (in the Sibyl case) or until other protocol changes are adopted (in the 51% case).
See also Do checkpoints in the block chain help to avoid a 51% attack that rewrites the entire blockchain?
These apply to both full nodes and thin clients.
Also, as mentioned in the post you linked, if you know you don't need to worry about these attacks, then you can decide not to verify every last detail of the chain before the checkpoint, which will save computation and let you sync the blockchain faster.