This seems confused. KML and SVG both use microsyntax to represent arrays of coordinates. They don't use XML markup. So processing the coordinates involves almost exactly the same logic (a couple of calls on tokenize()) that you would have to use with a CSV-like format. It's true XML isn't helping much here, but in what sense does XML get in the way?
That doesn't surprise me because SVG also uses the same interminable point series attributes that KML does (I suspect KML borrowed the idea from SVG). It's not quite as bad in SVG because there's usually much more to the SVG file than the point sets, but in KML files, that's in my experience generally the thing you really care about, and you almost wish it were in a fixed-width binary format instead.
So yeah, I can imagine a KML->SVG transform would be fairly painless (not that I've ever tried that myself), but I don't think that really rescues KML as a format. I'll also say that I can't imagine it would be hard to generate SVG from bog-standard KML data coded in a binary or CSV-like format. Again without the need for e.g. mixed content, attributes, etc, XML really just gets in the way.
If KML were represented in JSON you would be able to represent the coordinates natively as arrays of numbers, saving you a couple of calls on tokenize(). But in my experience the overall complexity of the processing task wouldn't be reduced in the slightest - unless you are using an API like the DOM, in which case you have only yourself to blame.