It does because that is solved trivially by documentation. By just work I didn't mean plug and play. (USB isn't really plug and play anyway by virtue of it being terrible.)
You can also design the protocol to auto-determine baud rate. Some protocols even transmit 0x55 at the start of every packet, allowing for clock synchronization.
Sometimes you get a device from a client who got it from another company who got it from etc etc. And it's been configured via internal memory to talk at some baud rate with some parity, and if you're really unlucky, it won't transmit unless it's received a command. And, like somebody else commented above, sometimes the Tx and Rx pins are just the wrong way around.
Your experiences with USB sound incredibly frustrating. But RS232 can also be crap in its own unique ways.
But to be fair, I do still rather like working on well behaved RS232/422/485 equipment, where you plug it in, set it to 9600 baud 8N1, and you just start seeing a stream of easily parsed text scrolling down your terminal :)
Most of the issues with RS-232 can be front-loaded though, and they are understandable. Once you get it going and document what's what, it's fine. For USB though, reaching an understanding of the actual problem is basically impossible.
With RS232 you can hook up an old oscilloscope and measure what the right baud rate should be. Even in the "won't transmit unless it receives" case, a sweep on a waveform generator and well configured trigger will get you on your way. USB you'd need much nicer tools handy to get to the bottom of an issue.
You are right on about the joy of it being 9600 8N1 on the first try.
