I'm going to have to agree with Martin Andersen.
Firstly a point about the audience of a program. While I am myself primarily a programmer I am occasionally asked to produce some graphics for my my company's products. However the task I'm trying achieve is produce an image. The relevancy of XML in this task is non-existent, the underlying representation of the graphic is of no value or interest for the task. In fact the only use case I can think of for ever exposing an XML tree representation of the image in production is for debugging purposes for the implementor of the software.
Secondly it is worth considering how this feature would be used. Having used some other image editing software one incredibly useful feature is the naming of objects in the document. Logically naming objects in a scene can be invaluable, particularly when collaboratively editing images. Another great use for an overview of objects is that of the object's history. Is the object a combination of a mask and a path? Is it a group of paths? All of this could be logically represented in a object/layer overview rather than the user knowing the underlying structure of the image itself. Also my initial feeling is that this would not be trivial to represent or even possible using a simple decomposition of the underlying XML document into a tree structure.
For me there are two unrelated bugs here: the issue of the XML tree view which could be improved to aid debugging of the software; the issue of presenting a user interface which helps people manage the elements of their document in a logical layer/document model. I'm not going to raise a new bug, though if asked I can do so with a full description of the feature in question, since this bug seems to be the most relevant bug given a quick search and I do not want to fragment the discussion of this feature. I hope this feature is given some more consideration.