I beg to doubt that Doug's judgement is based on any measurable or even measured facts.
This is how the USB HW works: you prepare a transfer by setting up transfer desriptors that point to the data to transmit. Then you kick off the HW which does the transfer completely autonomously, without any SW intervention.
The only thing left is to handle the HW interrupt that is asserted when the transfer is completed (passing the transfer descriptor back to the system, setting up the next transfer etc.).
This basic mechanism is about the same with USB 3 where USB 3 does have additional means to speed up things because I seem to remember it allows to define concurrent transfers (multiple transfers running partly in parallel). Again, it is the HW that does all the transfer, the SW part is negilible.
I don't see how changing SW from 16-bit to 32-bit can make that much of an impact but I am an engineer and not a believer.
USBMSD on the other hand is crippled by the fact that larger blocks of data (like one or multiple disk sectors) typically occupy more than one memory page (a list of "scattered" data). And then it would be helpful if the host controller drivers would allow to pass this scatter list directly to the HC drivers as the transfer descriptor mechanism allows to do just that: set up a list of discontiguous memory blocks to transfer. But this is not currently supported and therefore my workaround was to copy those scattered blocks to a contiguous piece of memory and transfer that in one shot. This DOES show performance improvement because people have already measured the performance gain.