I tend to make for a somewhat dubious champion of XML. Despite the fact that I use it daily, and that XML-based webservices have been a large part of my career (and the basis for the book I wrote), I think it is widely over-used. I tend to belong to the school-of-thought that believes you should have many tools in your toolbox, and you should use the best tool for the job. There are a lot of things for which XML is an excellent solution. But there are plenty of things for which it isn't, and some for which it's probably a terrible choice.
Just as some people are zealous in their criticism and avoidance of XML, some people are just as zealous (or more so) in their praise and use of it. In the cases you refer to casually above, you're talking about web-based technologies for the most part. In these cases, you generally already have an XML parser and/or DOM manipulator already available to you, so there is no harm in making use of it. You haven't added to the complexity, because it was already there. Flash & AIR make heavy use of XML for functionality, but they are targeted to an environment where parsing XML-ish markup (if not XML itself, then HTML or XHTML) is a core part of every application. For these technologies, introducing a different sort of data-expression language would be what adds complexity. Using XML makes perfect sense.
Here's an example... the language in question here is Perl because that's what I use primarily, but the Perl-aspect of it is not relevant to the point: I've been working on an extension of an existing module that dumps deep data structures. Useful for tons of things-- serialization, portability across platforms, etc. Also a popular tool for debugging. My reason for wanting to extend it is that truly large and complex structures (such as those produced by ORM or MOP frameworks) can get pretty hairy. So my first thought was to just make an extension that let me convert the data to HTML in a way I could exercise some control over. Then I thought that it would be nifty if I could create diagrams showing the various elements and which is linked to which, etc. Then it occurred to me that if I chose a reasonable neutral format, I should be able to derive both of those fairly easily.
That format? XML. Why would it be necessarily better than the native Perl serialization structure in this case, or better than using a different interim representation (such as YAML or JSON)? Because if I have valid, well-formed XML I can easily use XSLT to turn that into (X)HTML or SVG. I can also turn it into plain text if I want (I have XSLT stylesheets already, that choose to emit HTML fragments or cleanly-word-wrapped plain text depending on user selection).
There are plenty of ways to solve this particular problem, but the advantage that XML gives me in this case makes it the preferred choice (at least, for my preferences and my needs). XSLT is a well-defined, well-documented (OK, your opinion may vary on that with regards to the W3C documentation, but there is no shortage of books on the subject) tool for transforming XML into, well, pretty much anything. For this particular problem, the expressiveness of XML combined with the fact that my ultimate target formats (XHTML and SVG) are themselves XML, made it the clear choice. On the other hand, there have been plenty of times when I've recommended (as a consultant) to a client or (as a company employee/team member) to a boss/team that XML should not be used for some task. Sometimes the reason is clear-- using XML wouldn't improve the (re-)usability of the data, they weren't using XML on the project yet and this wasn't the sort of thing you should introduce that dependency for, etc. Sometimes the reason is more subtle; if you are trying to decide how to store/retrieve your application's configuration, does it really need to be in XML? It's highly unlikely any other application will need to read/parse this, so portability/reuse of data isn't an issue. If the data is fairly flat in nature you can probably manage with a file of key/value pairs. If the data is more complicated and/or complex, you might be fine with YAML.
In general, XML is the worst choice for data expression, except when it's the best choice. The same can be said for JSON and YAML, and the best way to get the most out of any of these approaches is to be familiar and comfortable with all of them and know which one is the best tool for the job you have in front of you.