Actually, most computers built in the last 15 years (providing they are 32-bit) will be perfectly fine with the 'sleep for 1ms' (or even the 0ms that you provided below)... The reason for this is that the functions do not guarantee that it will sleep for 1ms.
The system clock "ticks" at a constant rate. If dwMilliseconds is less than the resolution of the system clock, the thread may sleep for less than the specified length of time. If dwMilliseconds is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on.
So for a CPU where a tick is at the least, 40ms (which would be extremely slow), you're more likely to get 40ms or more of sleep time. That doesn't include task scheduling.
If you specify 0 milliseconds, the thread will relinquish the remainder of its time slice but remain ready. Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. For more information, see Scheduling Priorities.
The
/timer -ch (catch-up, high definition timer) is more likely to get 0ms on average, though it could cause input to mIRC to appear to "hang" on slower machines. Use with caution.
Also beware, if you're going to use the wscript.sleep method, of ping timeout! Because mIRC is (educated assumption) a single-threaded application, it can't do anything else while you're calling Sleep(), so it'll hang for the sleeping period, and possibly ping timeout if you call Sleep() for too long. I wouldn't recommend using Sleep() for mIRC at all, unless you absolutely know what you're doing.
