GPUs are special-purpose hardware designed explicitly for tasks like rendering graphics, and WebGL is based on a version from the late 2000s, based on insights from generations of high-performance computer games.
SVG is an XML-based bureaucratic-committee-specified document format from the late 1990s with a bunch of weirdly designed graphical elements thrown in, largely based on a drawing model invented in the 1970s.
SVG2 is/was an initiative to modernize it (and is to be finalized these days based on actual implemented features) but browser vendors have indicated they're only implementing a small set of conservative features [1] considering many vector effect features for UI are already part of CSS.
When SVG2 is finalized, it will probably just consist of a description of those SVG 1.1 and 1.2 feature actually implemented in browsers.
[1]: https://nikosandronikos.github.io/svg2-info/svg2-feature-sup...
But it doesn’t fundamentally change the concept, which as I said is to be a 1990s-style XML-based document format with a bunch of (frankly inconsistent and arbitrary) graphical elements in it, based on a 1970s drawing model. YMMV.
It’s great that it exists because browsers don’t give web authors any alternative method to match many of its capabilities. But it’s just as much of a confusing and frustrating mess as all the other web specs.
The browser doesn’t have any better way to do it. The performance will likely be good enough for whatever they are trying to do; CPUs are super fast these days, and can render many thousands of graphical elements at 60 frames per second even if you are forced to render everything in a cache ignorant and super-high-overhead roundabout fashion, and could conceivably do it all 20x more efficiently on bare metal on the CPU, or 1000x faster on a GPU.
If performance turns out to be unusably slow, they’re basically screwed, because the alternative (writing some WebGL thing from scratch) is way way harder.
There are a bunch of inherent graphical problems baked into SVG implementations (like compositing done in the wrong color space, lack of support for reasonable color spaces, inaccurate rendering of very fine features, phantom rendering of hairline gaps between immediately adjacent shapes, poor text layout, many components which are too inflexible to handle straight-forward goals, weird inconsistencies with other common tools, various bugs and cross-implementation incompatibilities, etc. etc.) but implementing a whole vector graphics pipeline from scratch to fix those would take years of work from a team of experts, something akin to implementing a video game rendering engine.
Someone just trying to make diagrams should live within the constraints of SVG and try to be happy with what it is, maybe with occasional grumping on a web forum.