Hi Herman,
In ChucK you can also go sub-sample rate (ie 0.5::sample => now;).
I wouldn't worry about the rate of the events (how fast they're generated), I think it's slightly more complex than that.
I would assume (and I'd like to ask someone on the list more expert than me to validate this statement) that as long as the event can be captured at low level by ChucK, then you can use it to trigger now.
In the case of USB MIDI then, there are also some aspects of the implementation of the various MIDI libraries that help in scenarios where too many msg are sent.
For example, the computer and/or the hardware connected to it, can communicate the fact that they're busy and thus whichever of the 2 is the one that sends the msg, can wait before sending the next one (all this assuming that both implemented USB MIDI the same way).
Now, as far as I know this mechanism is not always in place (both in USB MIDI libraries and hardware/software products), and I honestly don't know whether or not ChucK uses it (I suppose it would be the case of having a look at the source code - RtMidi and the way ChucK interfaces to it).
About now, this can work with dur and time data types and events (Event, MIDI, HID).
About the MIDI use case, your MidiIn objects receives a MIDI msg (so ChucK is aware of the msg already) and then triggers now.
At that point your script/program proceeds and go to the next instruction (ie whatever else in the code comes next).
Cheers,
Mario