80-bit collision resistance because of 80-bit x87 registers? This is just a curious question, and it probably doesn't belong here anyway, and I'm just being bold asking it here. 

80-bit used to be considered an adequate level of security, Skipjack and SHA1 were designed to be 80-bit-secure. But why 80 bits? Isn't 96 bits better because it's a multiple of 32 and gives a higher margin? 

Does the choice of 80 bits have anything to do with the fact that the 8087 processor has a 80-bit floating-point register as part of the design?
Coprocessors are designed for improved performance in a certain case, and in the case of fixed-width mathematics, I do not believe you would see a performance increase.

I am quite sure that 80-bits is simply because it is 10, 8-bit words, and not that it is targeting the 80-bit registers in a FPU.  Primarily, it would be inconvenient to use an FPU for this case due to the instruction layout.  In the case of Skipjack or a Feistel network in general, I do not know of any easy way to do the block swap without pulling the words out of the FPU back to the CPU to do the swap because the FPU hardware is designed around mantissa functions, not shifts and XORs.  You could use the FPU for intermediate storage, but because the x87 (this is particular case that is very x86 specific), you pull the 10-byte sequence from the stack, which would be more of a cost than just keeping it all in the integer unit.

Another note of security margins and Skipjack, it was designed for a minimally viable VLSI implementation.  If you were going to put something on an IC circa 1996, you'd probably lean toward 80-bits over 88 or 96, or larger.  MPEG-1, 2, 4 etc all had choices that were sub-optimal mathematically but the decoder ICs needed to be viable as a VLSI implementation. At meetings, this is always a constraint that comes up.  At NIST 8114, we've had the discussions but I've never seen these discussions formalized.  In power constrained computing, such as passively powered RFID, I still make engineering choices that are sub-optimal as far as ideal cryptography because bits cost money to make, power to use, and I don't have the luxury of increasing IC costs or power consumption.  Encryption often takes a backseat to economics in the same way that security does to convenience.