I'm inclined to agree with Joel Etherton's reasoning, but come to the opposite conclusion. The way I see it, even if you know that numbers are unlikely to ever approach the limits of a signed type, if you know that negative numbers won't happen, then there is very little reason to use the signed variant of a type.
For the same reason why I have, in a few select instances, used
BIGINT (64 bit integer) rather than
INTEGER (32-bit integer) in SQL Server tables. The probability that the data would hit the 32-bit limit within any reasonable amount of time is miniscule, but if it happens, the consequences in some situations could be quite devastating. Just be sure to map types between languages properly, or you are going to end up with interesting weirdness really far down the road...
That said, for some things, such as database primary key values, signed or unsigned really doesn't matter, because unless you are manually repairing broken data or something along those lines, you aren't ever dealing with the value directly; it's an identifier, nothing more. In those cases, consistency is probably more important than the exact choice of signedness. Otherwise, you end up with some foreign key columns that are signed and others that are unsigned, with no apparent pattern to it - or that interesting weirdness again.