Leaving aside the obvious subjective arguments (its verbose, the parsers are complex and slow, the spec is enormous, the data-to-markup ratio is bad) I'll talk about the data model of XML vs JSON.
First, the data model matches the data. Key/value pairs (hashes), lists and scalars are the primary means of organization. They're natural data structures that humans work well with. Look at the world around you, you will find them everywhere. Consider a simple form; a grocery list; describing yourself; listing things you did today; or email in your inbox. XML likes trees, and this is awkward. You can model everything as a tree, and from a computer science point of view its a very flexible structure, but it doesn't come naturally. Things tend to have some hierarchical structure, but not as the primary means of organization.
Second, the data model matches the native data structures of dynamic programming languages. I cannot stress this enough. Reading a JSON document into Perl or Ruby or Python or Javascript is trivial because it maps directly to native variables. You just slurp it in. XML needs to be transformed, because most languages don't do trees and graphs well. And you have to decide how you're going to handle attributes vs inner tags. Will you get <person eyes="blue">Joe</person> or <person><eyes>blue</eyes><name>Joe</name></person>? Each organization is going to have its own way of doing it with its own tags and its own idiosyncrasies which means extra coding for the developers. Look at the abomination that are Apple plists for an example.
JSON, by being so simple and having a data model which matches the nature of the data its representing, can only represent given data in a few plausible ways. So you don't need a schema, you can eyeball it. And because its data model matches the language's native data model, transforming data from a JSON document is as simple as transforming any other data. No tree manipulation required.
Now JSON is awfully limited, and there's a lot it cannot do. But that's ok, it is naturally constrained by its limitations. You can't make JSON do what it cannot do (not without a lot of work). XML is the opposite. It is generic and unconstrained. You can take almost any data problem and apply XML to it. Configuration files? Log files? Email? Project build files? Sure! Throw it all into XML! Add in that for a while XML was the only serious, generic data format out there, and it was being oversold as the do everything format, and you have a generation of technologies built with XML that are overkill.
XML was introduced when I started programming. It was hailed as the great savior of data interchange! No longer would you need to write custom parsers for whatever made-up data formats your business partners were using, just pass around XML documents! Its generic! You only need one parser! Which was a great leap forward, but it wasn't the silver bullet it was hyped to be. You still needed to interpret the data, which meant (if you were lucky) a schema file and transforming that awkward tree structure into something you could actually use. You wind up with a towering framework of XML technologies.
A lot of companies bought the hype, wrote XML documents any old way they liked and expected their data problems to just vanish. It didn't happen.
This answer started rational and naturally became frustrated. I'll try to sum up. XML has an awkward data model, its often overkill and it was oversold. If you need typed, hierarchical data, hopefully machine generated and consumed, its great! Usually you don't and so its mismatched to the task.
That said, I prefer YAML.