DC - Why should alarms go off?  There is a lot of data in the world that is better represented in a hierarchical structure than in having a relational structure imposed upon it.  Consider the simple example of HTML.  Obviously an HTML page could have a relational structure imposed upon it, but that would be awfully painful (look at the source code of this page and imagine it in relational format, for example).

For a more business-oriented example, consider ERP with its Bills of Material and Bills of Labor.  I've seen detailed BOMs that can go very, very deep indeed.  And I've seen the pain caused by trying to force a relational format on those BOMs (particularly in older versions of SQL Server where CTEs were not available).

As far as BOMs are concerned, and most hierarchical structures, there is more "value" (in one form or another) assigned as you move up the tree.  For instance, the $ value of a bicycle in a BOM increases as you add both tires to the frame.  And as you go up another level in the BOM, the $ value increases again when you add pedals.  In a standard business Org. Chart, the "value" you speak of might be measured in units of "authority", "accountability", or some other metric.  This is not a function of XML or even hierarchical databases themselves, it's standard practice when representing data hierarchically using any method, so I'm not really sure what you're driving at.  And yes, one of the features of XML is that position is important, as it can provide context to the data, as opposed to the SQL model which is order-independent.

Do you have a reference for all hierarchical data being able to be represented in "one and only one hierarchy"?  I would need a reference for that, as I can easily show a hierarchy like the following:

Bishop

   |----Priest

              |-----Nun

And I could represent the same data in a second hierarchy:

Pope

   |----Bishop

              |-----Priest

                          |-----Nun

So I'm not seeing what you're getting at there.  One subset of data represented in two different hierarchies.

And of course, using the SQL model I either have to assign them all the same attributes (i.e., Pointy Hat Color, Habit Size, etc.) even though for many of them it will be NULL (Nuns don't have Pointy Hats and the Pope doesn't wear a Habit), or create a separate table for each of Pope, Bishop, Priest, Nun representing their attributes.  And of course another table for Altar Boy, one for Church Janitor, etc.

Finally, in the example I gave, I'm talking about transferring a 100 MB XML file from the front end to the .NET app in the middle.  Further, after it's shredded we'll be transmitting maybe another 100 MB of network traffic from the .NET app to the SQL Server (depending on how much of the XML data we actually decide to keep).  If you eliminate the .NET app in the middle, you've just cut your network traffic in half.  I suppose I'm missing the irony of essentially cutting your network traffic in half...