#2 is actually a really big deal with developing software to interact with anything USB. Well, I should say anything based on the FTDI chipset. I don't have any experience with anything else. Which is increasingly the case, given the modern proliferation of hobbyest hardware projects. There are no connection status events. RS-232 never developed any because a loss of connection with a cable that is physically bolted into the computer should be a catastrophic event.
Oh, I cannot tell you how many hours of my life I'll never get back debugging connection status issues. And it doesn't necessarily have to be a physical break in the connection that causes the problem. It could be an every so small short in the connector that only triggers once in a blue moon when you shift yourself in your seat and accidentally bump the wire with your chair handle while also plugging in your headphones.
Luckily, the latest versions of Windows (don't look at me, clients don't seem to care that they'd save a ton of money using Linux) are pretty robust to USB connection cycles. It used to be, if you lost a connection before closing the connection, you wouldn't be able to close the connection. The USB device would get assigned to the same COM port, which you couldn't open, because you still had it open. But couldn't close. Because you lost the connection. In the later days of XP, it often led to having shutting down the program, recycling the USB connection, and start the program again. In the early days of XP, it required a whole system reboot.
#3 I don't actually begrudge anymore. It's a situation that occurred due to evolution. Regular B connectors are too big for small devices, so Mini-B was developed to accomodate. But it turned out that the design was significantly flawed, creating a board connector geometry that was not very robust against repeated pluggings and unpluggings. Micro-B was developed to be significantly stronger, to support a greater number of cycles (if you look closely, they aren't just a different shape, the pins are set in the plug completely differently). Then smartphones turned into micro-microcomputers and people started to want to plug devices into them. Suddenly, what was strictly a slave interface before, needed to have the option to become a master interface at will. USB-OTG was the result, and it's actually a rather clever compromise that maintains backwards compatibility well.
#4 can be a significant problem when doing any sort of real-time data collection. It's nearly impossible to connect a variety of sensing devices to a PC and be able to synchronize the readings of them in time. For the most part, I take the system timestamp for everything, then generate a best-fit curve and use that for my calculations. There's just no confidence in the precision of the time resolution in USB.
#5 isn't USB's fault, it's device manufacturers. Hardware developers are some of the worst programmers in the world (and yes, they will say the same thing about programmers and circuit design, but you don't see me designing circuits, now do you?). Your printer has a really shitty system for installing drivers because the driver developer can't be arsed to learn how the operating system works with drivers. And he can't be arsed because his manager is probably bugging him to "get back to real work".
His list of new problems are largely obviated by FTDI. However, FTDI has its own problems, both technical and political.