A 64-bit counter would certain extend the range well beyond any immediate concern, or possibly even beyond the likely lifetime of the earth or perhaps even the universe. However, the problem stems from the fact that only 32 bits have traditionally been allocated. You can't store 64 bits worth of information in space that has previously only been allocated 32 bits. Sure, for new programs, you could simply extend the length of the fields being used, but for legacy programs you may have a problem. Any data in the older format would have to be converted. Couple that with the fact that a lot of source code has been lost over the years, combined with people generally not even being aware of if or when these old 32 time fields were used, and you basically have a somewhat impossible problem. Keep in mind that this problem stems from storage allocation size, not the CPU register capacity. You can easily deal with 64 bit quantities on a 32 bit CPU. It's just that you'd need to process it 32 bits at a time due to the more limited register capacity, which of course means it's slightly easier and lazier to only use 32 bit fields if you can get away with it... for another few years.
Mind you, in 2038 we're only going to run out of Unix time stamp seconds for signed counters. Remember that Unix time stamps were for file creation/modification times, and it was set to a time before Unix came into use, hence there could be no files with "negative" times. In such a system, it makes sense to treat those time stamps as unsigned, in which case, that extra bit buys you another 68 years. Of course, people have found these counters useful to represent dates before Jan 1, 1970, such as when recording historical information, particularly birthdates of people who are still alive. (You only get to the early 1900's though with 32 bits, so it can't be too historical).
@CK9: When there's something strange in the neighborhood....
