USB is something that is possible to understand, and apparently bit-bang at at least low speed 1.5Mbps. Probably full speed 12Mbps as well on a modern MCU. I don't understand it, but one can.
In that sense it's like SPI, or perhaps more like CAN or SD: when you don't understand it, you reach for someone else to have done it for you, but you can choose to understand it and once you understand it you can implement it.
If you're the slave you have tight timing requirements but you only have to respond with certain fixed bit patterns to certain other bit patterns. If you're the master, you can do more things concurrently because the slave won't notice a little jitter in how often you poll it, but you have the problem of dealing with a wider variety of slaves that can be connected.
Oh, USB 1.1 at the transport layer and lower is not that difficult.
But there is more complexity on higher layers. USB HID (mice and keyboards) is often the first you'd want but it is special in that it allows a device to describe its own packet format in a tokenised data description language.
The device only has to send an additional blob when asked, but the host has to parse the contents of that blob and use the result to parse the device's packets.
And of course, every time there is complexity in a protocol and there are multiple implementations of it, there is more opportunity for them to be incompatible in very subtle ways.
This phenomenon has caused for example that some gaming keyboards with N-key rollover that work perfectly on MS-Windows without any special drivers have been rejected outright by Apple or Linux hosts. (I hope these issues have been fixed now, but I'm not sure).
I thought there was also a mandatory fixed-layout "boot" profile for mice and keyboards? There was some controversy because vendors interpreted it as only being allowed to support the boot profile, resulting in most USB keyboards having 6-key rollover maximum.
In a nutshell, yes. There's a flag for it (actually "subclass") for indicating being able to switch to the boot protocol.
Some hosts, especially BIOS:es, did check that flag but never sent the command to switch.
Keyboard vendors catered to the lowest common denominator because it was essential that users be able to enter the PC BIOS at boot.
BTW. Apple chiclet keyboards (before the "Magic") got an interested workaround to this problem for its proprietary Fn key. It uses a variation of the boot protocol but only a 5-byte array (5KRO). When the Fn key is pressed, the sixth byte will contain a code that is otherwise an error code if interpreted as the boot protocol.
In that sense it's like SPI, or perhaps more like CAN or SD: when you don't understand it, you reach for someone else to have done it for you, but you can choose to understand it and once you understand it you can implement it.
If you're the slave you have tight timing requirements but you only have to respond with certain fixed bit patterns to certain other bit patterns. If you're the master, you can do more things concurrently because the slave won't notice a little jitter in how often you poll it, but you have the problem of dealing with a wider variety of slaves that can be connected.