The design of Telepathy, and its approach to real-time communications
comes from a very specific rationale:
one component can crash without crashing others.
Ease of development:
components can be replaced within a running system; tools like
dbus-inspector can trace interactions between components.
components can be written in any language that has a D-Bus binding;
if the best free and open implementation of a given communications
protocol is in a certain language, you are able to write your
Connection Manager in that language and still have it available to
all Telepathy clients.
D-Bus has been adopted by both GNOME and KDE. Multiple user
interfaces can be developed on top of the same Telepathy components.
Components can be under different licenses that would be incompatible
if all components were running in one process.
Telepathy allows clients to ignore protocol details as much as
possible, easing transitions between different communications
Multiple Telepathy clients can use the same connection simultaneously.
Components can run with very limited privileges; a typical connection
manager only needs access to the network and to the D-Bus session bus
(e.g. making it possible to use an SELinux policy to prevent protocol
code from accessing the disk).