Yes, bit-banging using USB is also slow, because of the framing frequency used by the USB protocol.

That is one of the reasons why a bit-banged RS232 programmer connected to a USB-to-RS232 adapter does not work well. And the USB framing latencies will also affect serial stop-and-go protocols that sends tiny packets expecting constant acknowledges to be sent back.

It is a common trait that as the complexity of data buses increases, the intelligence needs of the devices connected will also increase to be able to make use of the bus. A complex bus can better handle multiple concurrent transfers, multiple masters, device enumerations, arbitration, ... but to be able to make use of a complex bus, the bus should just transfer the data, while the bit-banging should be performed by a slave processor on the receiving end.

That is why I wrote in an earlier post that it doesn't matter so much if a user has a slow or fast computer. The design of USB, PCI, Ethernet, ... will lead to slow bit-banging, where a 3GHz+ quad-core PC will lose to an old 286 PC running MS-DOS and having the program directly access the hardware.

Whenever schools or companies throws out old programmers, people tend to jump to pick up the programmers and then try to use them. And since they know they have a much better PC at home than the school or company was using, they expect to get the programmer to work well. And they expect that any little problem with a missing connector on the PC can be solved with a high-bandwidth bridge.

Today, there is hardly any cost at all to get a microcontroller with USB device support. Building a programmer around such a solution gives the bandwidth of USB - maybe not Hi-Speed (480Mbit/s) but at least Full-Speed (12Mbit/s) - while the microcontroller can perform I/O operations with us timings or better. Hardly any load on the PC, and without the bottleneck from the latencies of the PC interfaces.