Not all messaging protocols are the same. Different protocols may offer different messaging features, for example contact presence, avatars, geolocation, Voice-over-IP, etc. Sometimes a particular server implementation/version/instance won't have certain features enabled. Telepathy exposes the various available features for a connection as D-Bus interfaces.
The same might apply to channels. A text channel may be a one-to-one chat, or it may be a multi-user chat. The interfaces present on the channel tell us what its capabilities are.
Telepathy objects can be assumed to implement their base interface (e.g. Connection, Channel). The additional interfaces available on a Telepathy object are retreivable either via the Interfaces property (preferred) or the older GetInterfaces method call (e.g. for Connection, deprecated).
The interfaces for a connection/channel depend on the capabilities/type of the object. In general, most D-Bus language bindings make it very difficult to implement D-Bus objects with a dynamic set of interfaces, thus making it difficult for a connection manager to export a dynamic set of interfaces via D-Bus introspection.
If you use a D-Bus introspection tool (e.g. D-Feet to look at a Telepathy connection object, you'll find it announces support for all interfaces, even the ones it doesn't support. If you query the object's Interfaces property, you'll see which interfaces really are supported.
The Telepathy specification is still being improved and sometimes the specification provides two ways to achieve the same goal. Although one of the methods/interfaces will be deprecated, it's possible that some older connection managers do not yet implement the latest specification. In this case, it could be possible for your client to fall back to the older method. In general, deprecated interfaces and methods are not documented in this manual.