There is no way for a USB device to "interrupt" its host controller in the same manner as other hardware interrupts. USB does support an Interrupt transfer method, but this is in fact implemented by polling 1 and the latency one can achieve is about 1 ms, but ultimately limited by the host's performance.
You asked
Why does USB polling mechanism instead of interrupt to detect the device?
Well, one reason would be that the USB protocol simply does not support interrupts at all in the usual hardware sense, most likely to keep the protocol simpler. For example, if a device wanted to interpret a transfer that was in progress, it would have to signal this somehow, either by corrupting an existing transfer, or an extra signal line would have to be added to whole system. Quickly polling the bus in hardware is fast enough for most types of devices.
Note that detecting a new device fails all three of your points where polling is recommended. Indeed, we never know when to expect a new USB device to appear on the bus (#1), it happens rarely (#3) and in the device is not active detecting it immediately is not a priority (#2). Why waste time and energy checking for an event that is unlikely to occur?