"It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
Showing a different set of icons depending on the capabilities of other entities.
Not sending XHTML-IM  or other rich content to plaintext clients such as cell phones.
Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle  and Jingle RTP Sessions .
Not showing a "Send a File" button if another user's client does not support SI File Transfer .
Filtering Publish-Subscribe  notifications based on advertised subscriber interests.
In the past, after logging in some Jabber clients sent one Service Discovery  and one Software Version  request to each entity from which they received presence. That "disco/version flood" resulted in an excessive use of bandwidth and was impractical on a larger scale, particularly for users with large rosters. Therefore this document defines a more robust and scalable solution: namely, a presence-based mechanism  for exchanging information about entity capabilities. Clients should not engage in the older "disco/version flood" behavior and instead should use Entity Capabilities as specified herein."
Perhaps the main motivation for XIFF here, is to on the different set of icons. Nearly all clients implement them differently, and sometimes it is confusion to receive text version which is unfamiliar for the user.