https://www.spinics.net/lists/linux-usb/msg131265.html
http://www.spinics.net/lists/linux-usb/msg122354.html
http://marc.info/?l=linux-usb&m=134861220631257&w=2
http://www.spinics.net/lists/linux-usb/msg63980.html
...shit's so broken I could keep doing this all day long.
Most hardware on the market today was released before the xhci spec 1.0 was finished, and I agree that ALL hardware on the market does not even properly implement the spec that was available during its design. Fortunately, most issues can be worked around using quirks.
The hardware is the root of the problem, but I would also add that the xhci_hcd kernel module, even in the latest kernels, is well behind Microsoft in terms of handing these device-specific quirks. The Microsoft USB 3.0 stack introduced in Widows 8 solves just about every host-specific issue we've ever seen. ASMedia is the only host controller vendor that bothers to provide their own Windows 8/10 driver (both for their USB 3 Gen1 and Gen2 chips). No one else provides an alternative to the Microsoft provided usbxhci.sys. That said, all of our tests have been limited to bulk transfers, and we're only using existing user space libraries (WinUSB, LibUSB, IOKit). We do push throughput, we have tight latency requirements, and we keep a large number of buffers queued at all times, which does push the host controllers further than your typical storage device. (We make streaming data recording equipment for electrical engineers and embedded developers)
I don't want to bash xhci_hcd though; their progress has been fantastic, despite the minefield of problems created by all these host controller vendors. I would like to say a special thanks to @sarahsharp, for all of the hard work put into the xhci host controller module. Without Sarah, I don't know who will answer when the xhci_hcd doorbell rings.