Well ...
The way we use it, it's a way of stuffing multiple data structures into one field instead of having multiple child tables.
We have multiple products. Each product generates a "result", which is a collection of data. The data structure depends on the product. Rather than have a table for each product, we simply store every result as an XML value in the Result column of the Order table.
Besides saving us the incredible overhead of an extra join to the appropriate result table, this also allows us to change the data structure for a product without having to change the table. Simply write a new XML format into the Result column and you're done.
Don't point out that when you do that our XSLs to render reports has to be updated to recognize the two data structures and render each appropriately. Please also don't point out that since you can't create indices on nodes within the XML field you can't generate summaries of product outcomes. (eg: What percentage of product X yielded results in county Y?)
