SVG rendering is essentially little different from the rasterization of 3D graphics. You take mathematically calculated and stored data, and render it to pixels. The primary difference being the inclusion of mathematically calculated curves where most 3D interpreters are based on vertex and polygon data.
The reason why no one in game engines seems to support SVGs is that is because they are often more costly to render than 3D graphics, largely thanks to the previously mentioned smooth curves. Calculating curves frequently involves more computational overhead than just connecting existing vertex data. It's much less costly to render a vector image once, and then use that rendering until a different version is required.
You could compare it to real-time lighting and baked lighting. Real-time lighting can look better, and be more responsive. But baked lighting is WAY better for a game's performance. Constantly rendering SVGs would be terrible for a game's performance, while rendering an SVG to a series of different-resolution PNGs is much less costly. (and can provide similar functionality) Most people go for the latter approach.
I love vectors and SVGs. I use them all the time for graphic design. But if I wanted to use a vector approach in a game engine, I would probably limit myself to 3D graphics that I render to a texture.