This is way more complex than just basic bit-timing. At that level, USB is not that much different from UART - the specified max 20ns rise/fall time of driver, the expected 48MHz sampling (this is undocumented but expected quietly as it was typical max freq of cheap digital stuff of given era), and mainly the bit stuffing result in allowing surely a few % of bit timing error. [EDIT] see next post
However, there are also higher-level timing requirements, to ensure that the whole chain from device through hub(s) to host remains consistent under various pathologic situations. Read the first few subchapters of chapter 11 of USB (HUB) - the main point is, that if there's a runaway babbling device downstream, the hub must be able to cut it off so that it can detect SOF. OTOH hub must not cut short a downstream function's valid packet, so that downstream function (device, USB terminology is a mess) must not transmit beyond a certain point in time, that's why it must also obey some timing constraint. In other words, host's scheduler knows, that with hub and downstream devices not deviating more than 0.25%, it can schedule 12000-42 "perfect" bit-times for transactions within one frame.
As long as frame timing on the host port is not stretched to the limits, you won't see the effect of violating this constraint; yet it may result in very unpleasant effects (surprising unreliability/disconnects) in situations where the host scheduler starts to hit the limit.
There may be other reasons for the constraint, too. I did not write the USB spec.
In other words, as with all cases of "it works for me": go ahead, but then don't complain if it mysteriously fails to work in the future.
JW
PS. The standard of course stems from the technology of the era. RC oscillators are few % and that was obviously rejected for FS straight off; and the next best option were ceramic resonators, that's where the 0.25% comes from.
