There are plenty of ways why it might have been added for other purpose. A lot of keyboard APIs provide keyup/keydown events. The most obvious way for implementing that is by having a array or bitmask of all the keys. And once the keystate array is updated from usb packet, the information about order of keys in packet is lost. It also follows the principle of abstracting away low level hardware details. USB isn't only way you could attach a keyboard, there are also PS2 and bluetooth keyboards with different packet structures. Even for USB-HID the standard packet format consisting of bitmask for modifier keys + array of 6 other keys is only the default format guaranteed to work in BIOS. USB HID specification includes standard mechanism for defining the format of packets (report descriptors), which is one of the ways you can achieve more than 6-key rollover .

One plausible (to me) explanation is that the received scancodes are added to a bit vector (a "set"), discarding their original order. Some time later, the bit vector is iterated in numerical order.

Something in the back of my mind is telling me that it's actually spec-compliant to send the 6 scancodes in numerical order. Could very well be misremembering though, and most implementations accept near enough anything from an HID device in my experience

Appendix C: Keyboard Implementation from the Device class definition for HID states "The order of keycodes in array fields has no significance. Order determination is done by the host software comparing the contents of the previous report to the current report. If two or more keys are reported in one report, their order is indeterminate".