Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no dependencies, etc) in order to be adopted. And then validation was required to use it on system contexts not only trusted in-user-session contexts. It also had to swap in for both DCOP (KDE) and CORBA (GNOME). These were the choices that made it viable and why it became widely used.
Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation.
This is how open source works. People do what they care about. When speed came to the top of the list people did it.
Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.
Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation.
This is how open source works. People do what they care about. When speed came to the top of the list people did it.
Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.