You do need decently stable clocks for 232 and friends. Anything clocked by an RC oscillator is probably going to cause some sadness eventually.
I2C is terrible in so many ways. (Don't send it off-board. Just don't. Ever. Trust me on this one. I don't care what you read about the bus capacitance spec, do. not. do. this.) Sending out a clock on a 400pF on-card bus isn't too bad, but when you have a kilometer-long cable... yeah, we'd rather not send a clock down that, thank you. Hence the use of self-clocked or pray-we-have-similar-clock-frequencies protocols.
3.3V or 5V devices aren't RS-232 and people need to be careful about that. They're just UARTs with regular old logic levels. RS-232 or 422 or 485 are Serious Business levels to go out and do battle with the mean Real World and the only place they should ever land is at a dedicated transceiver. Full stop.
No, I'm saying you can't send I2C one meter off-board. Even six inches in anything but a gentle EMC environment can be severe trouble without careful design. And yet I've seen people try to run it ~180cm next to horrifying noise sources. Surprise, surprise, that doesn't work out very well.
The root of the problem is that I2C has serious EMC immunity issues. It's well known and appreciated that its drive is weak and open-drain. The bus buffers and especially differential drivers can and do help there. (And will get you past a meter.) What's less well recognized is that a single glitch pulse on SCK knocks all the internal state machines out of whack and requires a bus reset to fix them. Hope you're doing that when your bus is idle or when you're getting anomalies! Most people don't. The Nexus 4 phones sure didn't; this is why their light sensors went dead or crazy or both after a while of uptime.
All of that gets easier to handle if there's a nice, big, low-impedance ground plane nearby, which is why you don't see so much trouble when it stays on the PCB.
> oops, just connected 12V RS-232 to a 3.3V device
Maybe or maybe not. I ran 12V RS-232 levels into a 5V Atmel 8515 for a year or two 24/7 without issues, and tens of thousands, maybe more, have too. And that's a CMOS part.
(This was for a paytv interface sitting between an iso7816 slot and an x86 based emulator. The Atmel 8515 did the inversion in software).
The RS-232 on the PC side would have no issues with interpreting +5 as logic0 and 0V as logic1.
Some would setup a Max232 or Max233, but it wasn't necessary.
Others would use an MC1489 to at least convert the -12V and +12V into 5V and 0V by doing an input and then output into the chip, but again, it was out of caution and not actually necessary.
You can sometimes get away with this if your cables are short and your EMC environment is gentle. (An EE wouldn't try it, but only because sticking the transceiver in is quite easy.) You can never get away with this if your cables are long and your EMC environment is hostile. That's why we have 232 and, especially, 422/485: for when the job is hard.
Did it over ~100' of dollar-store grade RJ-11. (Maybe that's long, maybe that's short, depends on perspective). Was a residential environment, so EMC situation was nothing like some industrial environments.
When I was doing embedded work all our terminals simply remembered the last settings and it was like we would set it once and not have to think about it again.
The voltage thing is real (and real stupid IME) but we never ran into clock issues that would skew baud rates one way or another.
