I'm no XML expert, but kmj is begging me to weigh in :)
First of all, the programmers of the world do agree with you on buffer overflows and type errors. "Correctness" isn't the only factor when you code, you know. I know what your priorities are, being a linguistics student, but that's not what the driving factor is in business decisions.
XML is overly redundant. There's always a battle when designing a DTD between making some bit of data an attribute on an already existing element or a new subelement of an already existing element. This is the kind of redundancy that we all love that Python shuns -- it's a practically useless way to make things "different" -- it's The Perl Way, TMTOWTDI. Someone who knows XML better than I is welcome to explain to me why an XML programmer should use attributes instead of subelements, and that's fine, but it's still duplicated functionality.
Sublements and attributes aren't very different, syntactically, you are right. They are different in what they represent. XML is supposed to represent a structure, and certain things in documents lend themselves to being attributes of elements (such as the id and name) whereas some things are meant to be contained by those elements, not explicitly attached to them. In some DTDs, it is indeed difficult to tell the difference. For example, in DocBook, you often use an <AuthorInfo> block (I think it is, don't want to look it up right now) from within a document (that is, the document contains the AuthorInfo) to delineate who wrote the document. I think a better, more appropriate way of doing so would be to do something like <chapter author="StrikeInfo">...</chapter> and have "StrikeInfo" be essentially an xref to an AuthorInfo block with my info in it. So, yes, there are many ways of doing things, but you know yourself that there is no way of preventing this in any language, expecially one designed to be as general purpose as XML. Even Python has bad ways of doing things. XML doesn't encourage poor design any more than Python does. Python just has a bit more freedom in that it can discourage BAD design more easily because it's more complex.
XML is bloated. For the majority of uses of XML (including Jabber) the amount of text the XML metadata itself takes up is nearly as much or more than the amount of actual data tagged. It's wasteful for entirely this reason -- on the disk, it wastes space, on the network, it wastes bandwidth, and on the CPU, it wastes CPU time parsing it.
Oh please, you of all people bitching about CPU time? You are the one who advocates Python for many things and pretty much saying "CPU cycles be damned" unless they really need to be fast. Granted, a lot of the uses for XML are often more metadata than data, but so what? People are still developing microkernels even though the "metaprocesses" (i.e., the message passing between kernel modules) consume the VAST majority of the kernel processing time. It's a tradeoff some are willing to make, it's not up to you to say what is right or wrong except for in cases where you may elect to use it or not.
XML was designed to be easy to parse (they wanted it to be a two-week project for a CS grad student to write a non-validating XML parser). It was designed to be programming-language independent. But I don't think it's the best design for either of these (not that I'm offering any better designs).
It was also designed to be easy to read to humans (which, considering the vast amount of uses it has, it does a pretty good job). And until you DO offer up an alternative, your argument of "I don't think it's the best design" is nothing but opinion.