Why is SVG not supported by the TeX backend?

Classically TeX does not deal with any graphics formats, the dvi file file just contains a pointer to a graphics file to be included by the dvi driver. TeX just needs to know the space to leave, which it can read from a BoundingBox comment or from optional arguments in \includegraphics.

It is (usually) much easier to include a graphics format if it is the format that you are generating for the document, as the dvi driver doesn't need to "understand them", just copy into the stream, so for example dvips can include EPS files as they are just copied literally to the output, similarly jpg files, and certain bitmap formats that can more or less trivially be converted to PostScript bitmaps.

The situation with pdftex is similar except that it can not handle EPS files but can handle PDF files again because it is much easier to handle PDf if you are writing PDF.

To handle EPS in pdftex you need an external EPS to PDF translation program, which may be called by shell-escape from TeX, but is conceptually (and in fact) quite separate.

The situation with SVG is just the same. If you are producing svg (eg dvisvgm dvi driver) it is easier to include SVG than EPS or PDF, if on the other hand you are producing PostScript or PDF then you need a conversion program, usually incscape, in the loop. Again this may be hidden behind a shell-escape and called from TeX if needed. You should however convert the SVG to a scalable format (PDF or EPS) not to a bitmap, if the final aim is to include into PDF document.

Put yourself in the shoes of someone who is writing a TeX compiler. There are plenty of programs to convert images to one format or the other (inkscape, imagemagick's convert, ...); so why should you spend time on supporting more than one format, which would essentially be the same work as reimplementing a converter from scratch?

In particular, the SVG format contains everything but the kitchen sink: from bidirectional Chinese text on a curved Bézier path rendered in a custom font using a background color pattern, to a full-blown Javascript interpreter. Oh, the horror. No, thanks; your time is better spent fixing bugs and improving the core functionalities.

(Ok, most converters do not support the full functionality set of SVG, agreed, but the concept stands.)

So, in practice you just support one format (or maybe one bitmap and one vector format), and tell your users to use one of the many available external tools to convert graphics into it. Luckily, most of them are smart UNIX users, so they know their way around a Makefile or a build script.

If you want to be an excellent guy, you can support automatic conversion from eps to pdf, but even that is not your responsibility. Or maybe you could have a chat with the latexmk maintainer and ask them to introduce custom dependencies, so this can be automated from their side.

TL;DR: programmers do not like to reinvent the wheel.

Creating SVG graphics is supported via the dvisvgm package in the TeXLive distribution. It works by converting DVI files (produced by tex and latex rather than pdftex and pdflatex).