You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.
If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?
Far from it. One of the core designs of kbus (which dbus cannot do because it's not in the kernel) is that you can seal the payload buffer from the sender so the receiver and use it safely concurrently without having to clone anything.
There is obviously a lot of general inefficiency in the userland libraries but not in the design of it.
That was created for KDBUS but has more use than than being used for KDBUS exclusively. It still was written for KDBUS.
The real problem is he doesn't give any data for volume/bandwidth processed in his case.
I don't see why a "security policy driven message bus" would be more expensive than what he describes (unzipping, business rules encorcement, analyzing, etc).
It was in comparison with an HTTP server. I did not read much about the mail thread but from what I can tell it essentially benchmarks the uninteresting part of DBUS which is the part that runs in userspace. That's old and definitely needs improvements, but not the design of it. In fact, the design of KDBUS or the DBUS dispatching core is from what I can tell quite intelligent and makes sense from a performance point of view.
Without a doubt there are a lot of old bells and whistles attached to DBUS which need rewriting.