Renderer-agnostic is nice, actually, when you need to support lots of different browsers.
Some mobile browsers can't do WebGL as fast as they do Canvas, for instance. Other browsers will have a huge speed advantage with WebGL.
I'm not sure if any are faster with SVG, or the relative performance between SVG and canvas. But being able to do some test renders quickly in all three modes should allow you to select the fastest for a particular browser.
Game developers are better off with a game-oriented library, IMO. Even if you used something like Two.JS to do your rendering, there are a lot of things still useful in a game library to justify using it -- and most games will need more than geometric figures.
I love SVG support because it means you can render something in vector art in the browser which is also downloadable as a file by the user. Drawing stuff in the browser which is then stuck there is cute but lacks an important layer of interoperability with the rest of the computing ecosystem. So here we appear to get the best of all worlds: render to whatever is fastest in the browser but get automatic "export as SVG" for free.
Some mobile browsers can't do WebGL as fast as they do Canvas, for instance. Other browsers will have a huge speed advantage with WebGL.
I'm not sure if any are faster with SVG, or the relative performance between SVG and canvas. But being able to do some test renders quickly in all three modes should allow you to select the fastest for a particular browser.
Game developers are better off with a game-oriented library, IMO. Even if you used something like Two.JS to do your rendering, there are a lot of things still useful in a game library to justify using it -- and most games will need more than geometric figures.