I guess the differentiator is that Jacdac is a higher level protocol. RS232, RS485 and CAN are just 'send some data down this pipe' deals, and RS232/RS485 don't even have a particularly standard way of framing data. I haven't used SPI or I2C enough to know about them, but from looking them up, they also seem to just offer a way to send arbitrary data.
Jacdac both offers a standard way of using devices (from the website: 'devices with the same functionality but different hardware implementations can be substituted without having to recompile the application that uses them. For example, two different models of accelerometer hardware can replace each other because they share the same software interface.') and a standard way of finding devices (because all devices advertise the services they provide every 500ms).
Honestly, as somebody whose job involves a lot of interfacing with random bits of hardware, this would make my life a heck of a lot easier! There have been way too many times I've received a device manual for e.g. a Modbus-over-RS485 interface and had to go 'okay, is this list of register IDs zero-based or one-based? floating point or fixed point? big-endian or little-endian (or both in the case of one awful device!)' etc etc.
Indeed! Lots of Jacdac is not about the cable or the UART-based signaling, but about the service standardization and definitions.
Now if only we could get all these silicon vendors to put Jacdac directly on their current I2C/SPI sensors... It's definitely possible given that basic Jacdac implementation runs on PMC150C with 64 bytes or RAM and 1.5k of ROM, but it may be a hard sell since they seem to like lock-in.
It can be. K-bus in BMW and Rover cars is (was?) RS-232 plus collision sensing running at, I think, 19.2 k bps. It has single ended drivers with pull up resistors instead of push pull drivers. The K stands for karosseri meaning body.