The original SHA-1 and Skipjack specifications did not provide a justification for using a 80-bit key size, so we can only speculate about the reasons. However, it is important to understand that from a historical basis, an 80-bit key was considered adequate (barely) to be secure against exhaustive search for a few decades. It was clear that a 64-bit key size was not adequate, and a 128-bit keylength was more than needed. My own speculation is that 80 bits were chosen based on a calculation and extrapolation about how long a key was needed, to ensure a reasonable level of security against exhaustive keysearch for the next few decades.
The independent review of Skipjack is consistent with this viewpoint. Their executive summary states:
Under an assumption that the cost of processing power is halved
every eighteen months, it will be 36 years before the cost of
breaking SKIPJACK by exhaustive search will be equal to the cost
of breaking DES today. Thus, there is no significant risk that
SKIPJACK will be broken by exhaustive search in the next 30-40
years.
Source: SKIPJACK Review: Interim Report. Ernest F. Brickell, Dorothy E. Denning, Stephen T. Kent, David P. Maher, Walter Tuchman. July 28, 1993.
Why not a longer key? Well, there are two reasons:
A longer key (or security to greater than $2^{80}$ level) would leave you with a slower algorithm. For instance, SHA-1 would have been a lot slower if it had been designed to provide a 128-bit level of security, rather than a 80-bit level. Moreover, performance was a big deal at the time -- much more so than today. Developers routinely shied away from using cryptography because of fears over its performance impact. So, choosing an unnecessarily long keylength would have made the algorithm even slower, possibly leading to even less use of cryptography, which overall might have been worse for security. As a 80-bit level was considered adequate, there were good reasons not to make the algorithm slower than needed by seeking a longer key.
In the particular case of Skipjack, it also seems likely to me that the NSA did not choose a longer key length to avoid contributing to the spread of strong encryption. Remember that Skipjack was designed during the height of the crypto wars, when the NSA's policy was to limit spread of strong cryptography. Also, Skipjack was designed to be part of the Clipper key escrow initiative. I imagine the NSA expected that the Skipjack algorithm would become public, and they didn't want to share their best, strongest encryption technology with the world. Skipjack's design is interesting in that its key length is "baked into" the design of the cipher: it isn't obvious how to increase its key length, without losing its security properties, and multiple aspects of the cipher (the key length, the number of rounds, etc.) all appear to have been chosen carefully to provide exactly a $2^{80}$ level of security -- no more, and no less. So, the NSA might have chosen a 80-bit key as a key length that is adequate to support the purposes of the Clipper key escrow initiative (or to support commercial purposes), while at the same time being no longer than necessary (to avoid contributing to the proliferation of cryptography among the enemies they wanted to spy on).
Finally, I would like to point out that the conclusion of approximately 80-bit keys being (barely) adequate was by no means out of the mainstream. At the time, I think a 80-bit level of security was viewed by many as sufficient and a reasonable engineering choice. For instance, an analysis done Lenstra and Verheul about 10 years later recommended symmetric keys of 86 bits and hash functions of 172 bits, to achieve security until 2020; this was often summarized as 80 bits is about a sweet spot. See Selecting Cryptographic Key Sizes, Arjen K. Lenstra and Eric R. Verheul, J. Cryptology, vol 14, 2001, pp.255-293.