The only time something should even pretend to know anything about its own status is if its a fully programmable keyboard being run from a teensy or something and you have different layers.
That's actually a strike against the OS trying to be too smart. It limits the ability of designers and end-users to come up with creative and flexible solutions to their own workflow.
The other common strike against OS overaggressiveness is the point of this very thread—using a separate numeric keypad. There are two setups where this is common: With a notebook where the keyboard does not have room for a separate number pad, and TKL keyboards. (In my case, my TECK falls into the latter category.) In both scenarios it's common for the keyboard design to include an embedded numeric keypad to make major number entry easier. For such an embedded number pad to be appropriately useful there needs to be a number lock feature (so your left hand can be on the paper to keep track of where you are).
So now you have a problem. When the number lock on the keyboard is off so you can type, and that number lock is system-wide, does that now mean the numeric keypad you've added
must not be permitted to send numeric codes? That is the situation we have now.
The result is that the keyboard and keypad designers must come up with a workaround. One option is to have the number pad send the number codes for the top row numbers instead of the numeric keypad codes. But there is software that needs to perform different functions based on whether the number was typed on the keypad or the top row. One example is the music notation software I use, and I can tell you, that
needs to be that way.
Another option is to toggle the systemwide number lock when passing the number code. But that can run into timing issues. There's a reason good keyboards have N-key rollover: because when things are happening fast, events can become so close that they overlap and interfere with each other. Toggling the system number lock in that situation can lead to unexpected results if the lock is still on when a second key's event is processed, which can happen with multiple devices.
You mentioned one advantage to a systemwide state: keeping the state of multiple devices in sync. But think about it. When does this make sense? When each device is different? (As in the notebook/TKL keyboard + number pad) Or when each device is the same? (As in two dedicated number pads.) If the latter, would the end user always want them in sync? Or put this way, why would the end user add a
second number pad if they wanted both of them to do exactly the same thing?
Another possible reason to use a systemwide state is to simplify keyboard design. But if you think about keyboards, they always have to track the number lock state anyway to turn the LED on and off. So I don't see any technical reason to not have each keyboard track it's own state(s). Heck, it's done for caps lock.
