It seemed like the author's original problem was having to do so over and over to deal with different pixel densities, but this is exactly the sort of problem SVG exists to solve. I do admire the technical skill, I just don't get the attraction of compiling ascii art into a vector image for anything practical, for much the same reason that I wouldn't want to use Photoshop or Illustrator to write code.
Maybe because it is (or at least can be, the more advanced usages become less so) tolerably self-describing in that you can readily see what it is producing, in a way that SVG isn't, while still being source-control and diffing-tool friendly text?
For small things like its intended uses, it fits well within coding tools and workflows, and avoids separately documenting and coding the art.
This kind of reeks of "If your only tool is a text editor, every problem looks like text".
Just as with programming, polyglot programming has value, but switching languages within a project had a complexity cost that isn't always justified even when for dinner task taken alone a different language is marginally superior.
For some applications, having something be both can be helpful.
Because programmers typically prefer typing in ASCII to drawing :-)
There has to be something wrong with SVG when people even thinks drawing icons in this day and age in ASCII is a must do.
Pixel alignment, asset management and being a one-man shop allowed more excentricities is what justifies this, for small icons with simple features (a few straight lines or rects).