I have to feel that the article is short sighted and reactionary.
I used to shy away from XML for the same reasons the author stated, however over the years I have had a change in heart.
Definitely, if all your interested in is efficiency than XML is not the right choice. At the enterprise level, often there is a need to combine similar, but different sets of data together to make something more useful. XML is a more flexible approach to the problem, and can speed a project to market more quickly. I am continually amazed how often doing the right thing from a IT perspective is often the wrong thing from a business perspective. If a project takes too long to come to market because the engineers took the long way around, the business opportunity can be lost. XML can be a fast way to your end goals, but certainly not the most CPU cycle efficient.
Too, continually I see opportunities and the need for data structure to be more flexible, as Michael Taylor points out in his post. Reality is that most of the data stored on computers is unstructured or at least not structure enough to fit with a DBMS model, but we would still like to relate to it with set theory. Can a DBMS help? Certainly, and tools that facilitate that should be welcomed. We all love a smooth running well designed perfectly relational databases, but sometimes we have other needs and goals that are more important. We should not fear what is outside our box.
That said, I do look forward to XML's successor and it's possibilities.