My posting above was based mainly on what I learned at an AES presentation about USB for professional audio, back when USB was around the 1.1 version level. It wasn't highly regarded for professional audio at that point, but not mainly because of bandwidth per se. Even then the bandwidth was sufficient for some applications. But that sufficiency was based on uninterrupted good conditions--mainly, on not using the same computer for anything else or putting any other peripherals on the same USB bus (sorry, that's redundant the way "ATM machine" is redundant).
The USB protocol for host devices had no provisions for catering to peripherals with a specific throughput that MUST be available under all conditions, e.g. even if the host computer is unusually busy, or if other peripheral devices on the same bus also raise high demands. USB was designed to handle as much data as it could, given the demands from all attached devices and the availability of CPU cycles and memory from its host device (PC or whatever). It was designed to "fail gracefully" when those demands exceeded the available bandwidth, so that if circumstances didn't allow it to convey certain information, it would carry on without locking up or requiring user intervention. To put it another way, it was designed to conceal its failures rather than communicate them.
For a number of years most high-quality professional audio equipment that was designed for connection to PCs used proprietary option cards that plugged in to the host computer's motherboard. That was expensive and required a lot of extra development time, not to mention the inconvenience of opening one's computer to plug the card in (and the fact that laptops were thus ruled out). Clearly USB, FireWire and other similar protocols would be preferable if/when they were up to the task. There was enormous market pressure to switch over to them, ready or not.
Fast forward to today; I've got ~15 USB 2.x or 3.x devices attached to my PC, many via two outboard "hubs". There are at least four independent host devices on the motherboard of this computer. So each hub is subject to contention among the devices attached to it, over which I have no control nor even any way of monitoring; each bus is subject to contention among the devices attached to it, over which I have no control nor even any way of monitoring, and each host device on the motherboard, likewise. The Windows device manager doesn't identify these peripherals in a useful way nor show the overall layout of hosts vs. peripherals to let me balance the loads among the available buses. Maybe I have always had 20 times more available bandwidth as I have ever needed; maybe internal buffering on the peripheral side is always enough to get through the rough spots that I happen to have; maybe on a good day everything has sufficient margin, but during certain tasks it doesn't. I couldn't tell you, because the system is designed to keep on functioning at a reduced level of performance rather than complain. And reduced performance in this case means ignoring a peripheral that is asking for attention that can't be granted at that moment.
Some of the devices that I attach via USB include disk drives. When copying files to and from them, the equipment and the operating system obviously follow strategies to make sure that bytes aren't dropped. But as users we can see that the data transfer speed is allowed to vary during such operations. When writing large numbers of small files to a drive, for example (especially a spindle drive rather than an SSD), everything slows way, way down as it must.
Now maybe in the meantime the USB standard has been developed in exactly the needed direction, so that a bus will configure itself when a certain class of peripheral device is attached, pre-allocating host resources on a basis that guarantees uninterrupted, error-free isochronous data transfer. There are apparently some elements of that in effect nowadays--but what do they add up to in practice with typical, current implementations, or with the arrangement that I have on my PC today? I don't happen to know the answer to that, other than "all the other kids are doing it, so it must be OK." And I'm just pointing out that yeah, maybe--but it's really strange not to know or even to have any way of knowing.
--best regards