What seems to be a hierarchy comes from the fact that this is a serialization of the data and the serialization has to be sequential and thus you cannot have a true graph here, only a tree with references. This would be true for any serialization format. Once you deserialize this into your internal format you can have back your graph and it can be as efficient as you'd like.
As a serialization format, however, it's very good, because it's based on a good standard. What's especially good about it is that you can see through its structure and access parts of it using the same generic API as with other XML-based formats. For example, in the browser you can style SVG with the same styling you use for HTML or script it with JavaScript.
I just looked, and apparently the matrix values can contain arbitrary whitespace including newlines, so even that's not a very strong criticism. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feC...
<svg class="defs-only"> <filter id="duotone" color-interpolation-filters="sRGB" x="0" y="0" height="100%" width="100%"> <feColorMatrix type="matrix" values="0.90 0 0 0 0.40 0.95 0 0 0 -0.10 -0.20 0 0 0 0.65 0 0 0 1 0" /> </filter> </svg>
SVG is a horrible way to do graphics, and not a good vector format due to its complexity. It's also difficult to get good performance, you'll eventually end up implementing stuff at a lower layer when SVG itself becomes a bottle-neck, and it has tons of cross-platform bugs that require endless debugging.
The crux of the matter is vectors are drawings, and may or may not have a hierarchical representation. It would be a lot better abstracted by a real language, using a primitive drawing API that allows you set debugger statements and the like to inspect state, variables, etc.