One of my take-aways from the last week (both presentations at eComm and discussions I've had with various developers) is that, more and more, people see themselves as building applications. Not web applications or phone applications or IM applications, but applications. The web is one interface into an application, but the phone (either voice or SMS) is another, and IM-like technologies are yet another.
Consider Twitter. You can go to the Twitter website and input a "tweet". You can send SMS to a certain number and input a tweet that way. You can also do so via a Jabber bot that they wrote (then rewrote as a component because the bot didn't scale -- but that's OK, bots are a good place to start :-). You can also receive tweets via IM because that's a natural way to receive information in real time (and, as I've been saying for a few years now, we're slowly but surely building a real-time Internet).
Now, it's mildly interesting that the Twitter developers see the possibilities of XMPP on the client side. But more significant is that they see the possibilities on the server side -- Blaine talked about this in his presentation at eComm the other day. A real pain point for them is all the polling that other web services do against their system. Every minute or 5 minutes or 10 minutes, some web service (say, Jaiku) will send an HTTP request to find out if my Twitter feed has changed. Multiply that by 500,000 Twitter users and dozens of web services, and you quickly see that Twitter will have a hard time scaling their offering.
Enter XMPP. If Twitter can convince all those web services (and clients like Twitterific) to use XMPP, Twitter can push out information only when it changes (via the XMPP pubsub extension) and therefore can save a tremendous amount of bandwidth, server hardware, and developer heartache. This is the direction that Twitter is pursuing, and the same is true of other large social networking services like Yahoo's new FireEagle location service (as I discussed at eComm yesterday with rabble), Jaiku, Dopplr, and so on.
This is one small example of how XMPP technologies are helping developers solve real problems in the real world. There are many other examples from large and mid-size enterprises, government agencies, service providers, public-facing Internet services, gaming services, software developers, etc. Unfortunately, so many of these organizations consider XMPP to be a big part of their secret sauce that often the word doesn't get out that you can use XMPP to solve all sorts of interesting problems. But thankfully that is slowly starting to change, because you can't keep a good thing bottled up forever... :-)