Because non-modifier actions are enacted on the key down event.
This is actually almost nothing to do with keyboard hardware. Both USB and PS/2 keyboards operate the same in this respect. There is nothing in the hardware that makes so-called "modifier keys" special. Any key, with one exception, can be a modifier key or not.
What determines what is a modifier key is the keyboard map employed in software in an operating system. The hardware just sends what are in effect (glossing over the details of the USB HID input report protocol actually being a bitmap of currently pressed keys that is partly encoded into an inside-out form to keep it short) key down and key up events.
In a FreeBSD keyboard map, for example, one finds lines such as this:
# alt
# scan cntrl alt alt cntrl lock
# code base shift cntrl shift alt shift cntrl shift state
# ------------------------------------------------------------------
…
029 lctrl lctrl lctrl lctrl lctrl lctrl lctrl lctrl O
…
042 lshift lshift lshift lshift lshift lshift lshift lshift O
…
054 rshift rshift rshift rshift rshift rshift rshift rshift O
…
056 lalt lalt lalt lalt lalt lalt lalt lalt O
…
083 del '.' '.' '.' '.' '.' boot boot N
…
029, 042, 054, and 056 are the keyboard codes (normalized into a common system from the USB HID usage numbers and the PS/2 scancode numbers) but it is the lctrl, lshift, rshift, and lalt actions in the map that define these keys to be modifier keys. Define them with different actions and move these actions elsewhere, as indeed several out-of-the-box FreeBSD maps do, and entirely different keys are modifiers.
(The exception to the rule is the Fn key, which is the one modifier that is implemented in hardware. It is implemented entirely in hardware and not seen by software at all. It does not even generate any events over the wire. There's actually another hardware modifier, too. It isn't a key. It's the state of the NumLock LED.)
The action, when it is a modifier action such as this, changes the current modifier state, which (simply put) is a set of flags recorded in the operating system that record what modifiers are currently "on". As you can see from the column headings in the keyboard map, the current modifier state — in terms of "on" flags for "shift", "altgr", "control" and "alt" states — influences what action further keypresses map to.
On the line for key code 083, which is the one engraved . del on the numeric keypad, you can see that only if the current modifier state is at least "alt cntrl" will the mapped action be boot.
Keyboard drivers enact modifier actions upon receiving key press or key release events. Other actions, however, only take effect upon key press or autorepeat events. This is the case for the boot action, for example. Only if a key press or autorepeat event for key 083 occurs and the current modifier state is already "alt cntrl"/"alt cntrl shift", does the boot action happen.
It should be obvious from this that in order to get the operating system's current modifier state into that state in the first place, the lalt and lctrl/rctrl actions must have already happened, by first pressing the keys that happen to be mapped to them. (FreeBSD's system also allows for modifier locks in addition to the usual system of modifier shifts, although only two keyboard maps out-of-the-box make any use of them at all. The ISO keyboard standard also allows for modifier latches, but FreeBSD does not provide this mechanism.)
FreeBSD is, as I said, an example here. But most operating systems with PS/2 or USB HID devices, from MS/PC-DOS (where the current modifier state is a well-known byte in memory) to Windows NT (where keyboard maps are kernel-mode DLLs containing code and data), work in roughly this way.
Further reading
