This probably deserves a long blog post or something (maybe I already wrote it somewhere) but here's a teaser.
dbus is not mostly about IPC.
Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use a "swarm of processes" architecture. This is as opposed to an alternative like smalltalk, Eclipse, Firefox, or Emacs where lots of plugins are loaded into one huge process.
Problems common in server side IPC which aren't as big an issue here: scalability; network partitioning; protocol interoperability.
Problems which are more of an issue: service discovery (can't just use DNS); tracking lifecycle of other processes; inherent singleton, stateful nature of hardware, the kernel, and user interfaces.
The main way dbus helps with this is the star topology with a daemon that can start on demand and track all the processes. IPC is then coordinated with this in such a way that race conditions can be avoided, for example you can start a service and send it a command without a race that your command arrives too soon.
Anyhow this is just enough to get an interested person tracking down the details, I'm not spelling it out obviously.