Part of the problem was that browsers never really fully optimized svg, especially with CSS. Animated stroke patterns were especially rough, if my memory serves.
SVG rendering on browsers is still sub-optimal, which I think is a shame as SVG has great potential if it was treated as a first-class element on the web. Recent improvements to the code driving (2D) Canvas API canvas elements shows that this work could be done across browsers. The big thing holding back development is possibly the continuing failure to finalise the SVG2 standard?
It's sub-optimal in that browser developers have - for a number of legitimate reasons - chosen not to spend their time building SVG engines into their browsers that are efficient, robust and fast. I think its more a story of benign neglect rather than active discouragement. Compared to the Javascript and CSS engines, which have improved massively over the past decade, SVG remains ... serviceable for basic requirements (simpler stuff - static graphics, icons, etc), but nothing more. If that makes sense?
I don't know anything about the browser internals or the development process/plans, but I've used requestAnimationFrame to animate SVG graphics from JavaScript and it has been super smooth for me even without a modern graphics card (only on-board graphics). The only time I've seen a performance degradation was with a complex filter involving blurs and specular reflection.
I was doing some pretty decent rendering in HTML4 back in 2008.. supporting various browers (let alone IE6, 7 and maybe 8 at the time)
Around 2010, I did experiment with things like Silverlight and SVGs. SVGs was OK, but the performance quality was not there. It might be a lot better now.