Finally, regarding the suggestion of a continous input poll while waiting, I think this wouldn't mean any difference, as inputs are event driven rather than polled. So think about the inputs as messages that get stored in a mailbox. It doesn't matter if you check the mailbox 100 times in a day or just once before you go to bed, the amount of messages you will pick during the day is the same.
Given that human reaction time when measured from sensing (with eyes or ears) to muscle action is physiologically taking on average more than 200 (two-hundred) ms, it's impossible for a human to react to something -unexpected- happening in the first 1/3rd displayed on screen and move the joystick in that same frame.
When folks are considering input "lag", the two quotes above are very important. I believe that when people hear the word "lag" they infer the meaning to be that it will slow them down somehow. What needs to be kept in mind is that everything is relative. In the world of electronics, things are moving at speeds which mere humans cannot comprehend without using mathematics to represent them. At a certain threshold, everything becomes instantaneous with regard to our abilities to sense or react to them. To put this further into perspective, even light traveling in a vacuum has "lag", but unless it's origin is 186282 miles away, it wouldn't even take a second to reach your eyes. In the sense of display frame timing, 60hz was selected first because it was easy (electricity in North America runs at 60hz) and second because it's well above the 24 fps found to be the minimum for film to produce continuous, "flicker-free" motion images for viewers, at a time when high frame rates were impossible or prohibitively costly to create.
In the case of whether or not emulation can provide the same experience as actual hardware, it all operates relative to the same, very small scale. The fact that elaborate, frame accurate capture setups with LED indicators are necessary to flesh out what is happening at that level, is proof enough that it is happening at speeds which are well beyond our "instantaneous" perception threshold. So those who believe they experience lag which can affect their play, due to being a half, or even a full frame behind, are very likely doing a bit of projecting. But as Calamity states, fast systems should be able to do what the original hardware does for each frame, which is, in simple terms:
Check input
Calculate result based on input
Display result
Repeat
So whether user input is checked once or a thousand times, it will make little difference to the code, as it must do these things in the above order. Any input buffered after the initial check, will need to be acted upon in the next frame, as it cannot stop what it's doing and recalculate the result in midstream. The original code is likely to be further limited by allowing only one data transition for each frame which is calculated. So in the case of the example used earlier, either the ship moves one pixel per displayed frame, or it does not. Having these movements queued 1000 times over, as opposed to just once, will make no difference to the code.
So, given the above, "low-speed" (again, a
very relative term which has no bearing on human perception) USB devices which report the states of all controls at 8ms intervals (i.e. twice for each generated frame) are
more than sufficient. Therefore, 1 ms polling intervals are entirely unnecessary, and really only adds unnecessary system overhead and bus traffic.
The most important thing to look at with controllers is the manner in which input is processed. For example, a controller which transmits it's states 1000 times a second will not be advantageous if that controller takes 20 or 30ms to decide whether the status of the devices connected to it have changed. It will simply be uselessly transmitting exactly the same data until it does. Those who might believe that it's important to get an input message in "under the wire" before the inputs are polled and when processing begins, really need to take a hard look at the extremely tiny fraction of time where this occurs, and honestly assess whether there is any practicality there whatsoever. And if there's not, then adding more burden to the system in the way of higher polling rates, doesn't make sense, and may actually work against the goal.
Then, take a hard look at the actual devices (buttons, joysticks, etc,) and decide whether these are offering the performance you expect for the types of games you play. There is a vast difference in the mechanics of varying devices, which can lead to a delay between the time you
intend to perform an action, and when it actually gets to the point of indicating to the controller that something has changed. If this is the cause of issues for you, even original arcade hardware would show them, with those devices attached.