hHe short version: http://lwn.net/Articles/551969/
At first, this sounds like the kernel developers have raided LP's "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".
There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.
No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.