Thinking back a little bit more. The choice of sec and nsec was to keep the timestamps human readable on introspection. Reading a sec, nsec tuple is relatively easy for human readability and understandability. You loose some amount of time representation into the future since not all 64 bits of data are useable. But human readability is valuable.
There are things that can provide higher accuracy than the unix timers. Some sensors etc rely on that level of precision.
Clearly in most cases you will not need the full resolution. But how much do you save if you use microseconds? If you use a 64bit representation nano-seconds will work for more than 500 years past the epoch, while microseconds will last more than 500000 years past the epoch. A 32bit representation is not adequate for either microseconds or nanoseconds to represent the current date past the epoch. Picking a width between 32 and 64 is likely to just need padding for most operations and the additional complexity is makes it undesirable.
Since you cannot really make the data more compact by dropping 3 significant figures, I would suggest that supporting the higher resolution has more potential uses than being able to plan millenniums into the future.
Just pasting in some comments from @tfoote: for ROS1 I don't think we have design documentation. We wanted at least nanosecond resolution and wanted at least 64bit resolution. We've been thinking of just using just uint64. I think in the early ROS iterations we didn't consider uint64 as standard.