clarity of concept

If it's any consolation it's much simpler than CORBA or COM. Go try to figure those out!

I think the gap is simply that if you haven't done UI development (GNOME, KDE, etc.) you don't see the problems dbus solves. But dbus has been successful for a reason.

What dbus helps you do is build a single UI from a swarm of processes on a single machine. That's the fundamental architecture of GNOME and KDE (and other traditional X setups, too).

This involves IPC, but also discovery and lifecycle problems. How do you locate and use a service? How do you ensure there's only one copy of a service? How do you close down all the services in a user session? Stuff like that.

dbus and its protocol are really just modeled on X11. dbus services = X selections, dbus messages = a thing you could have hacked on X client messages if you wanted to, etc. With dbus though it isn't tied to an X session and is less hacky, and so it can also be used for systemwide services and stuff.

Prior to dbus, GNOME and KDE both tried CORBA, and KDE had a dbus-like system called DCOP. dbus is really just a code cleanup of DCOP in some sense, and DCOP was a (drastic) simplification of CORBA. Both desktops were also using various hacks layered on top of the X server which were replaced by dbus. So there was a lot of prior experience and dbus was the synthesis of lessons learned.