EDIT: Seems to be answered in the FAQ: "We have decided to use the Canvas object as the main backend for now because it is faster than SVG and allows us to implement and optimize our own Scene Graph / Document Object Model. We will be offering SVG (and hopefully PDF) importing and exporting in the future."
It was also abandoned as soon as Adobe acquired Macromedia, and thus Flash, meaning that there was no longer any reason for Adobe to push for a Flash alternative. There have never really been any good implementations, and it seems as though the spec wasn't written by anybody who'd have to eventually write an implementation.
Also, what's wrong with the mainstream SVG implementations, like in WebKit and Gecko?
From what I can tell the browser implementations are getting much better. It has been very odd that browsers have been shipping half-broken implementations for years, and the specification was released in 2003, a full eight years ago.
I think that the failure to implement SVG can largely be traced back to the extreme breadth and complexity of the specification. It's much easier to read through the specification for OpenGL or Postscript than it was to make it through the SVG specification, though I admit that a procedural API is almost necessarily simpler and easier than a stateful scene graph that includes a procedural API on top of it. Maybe SVG Tiny and Mobile mitigate the problem, but those came far too late to make a difference, and SVG 1.1 certainly wasn't deprecated in favor of a smaller and more implementable set of functionality.
In ay case, I'm not going to be guinea pig for SVG again. I may pick it up when others have proven that it has several interoperable implementation on separate OSs, but I still consider it one of the bigger time-sucks and poor architectural decisions I've made. /rant
I do think it's unfortunate that lots of W3C standards like SVG were well-positioned to be very widely used, but ended up being so big, complicated, and not informed by actual implementations. I've ranted about this before: http://news.ycombinator.com/item?id=2521885
Given how clunky SVG can be, it's surprising that this technique works so well. I believe the performance gain comes from batching everything you want to render into a single ginormous round trip between JS and native code. With Canvas, you don't have that option, so you have to cross the grand canyon with every call. The equivalent in SVG would be making a series of tweaks to the SVG DOM, and that's even slower. Much better to rebuild the entire DOM yourself in text and overwrite the old one.
As a bonus, you can take the same approach in IE using VML. Though the markup is different, the SVG and VML models are close to isomorphic - not close enough to abstract over without an annoying impedance mismatch, but much closer than either is to Canvas. Thus this technique affords a good way to get graphics performance out of both the modern browsers (SVG) and the pre-9 IEs (VML) for as long as the latter are around.
I'm pretty sure Paul Irish's talk [1, 2] is where I read about this.
We've tried all the alternative techniques you mention (with HTML DOMs, that is - I don't think any of them work with SVG) and had disappointing results.
Raphaël on the other hand, provides a simple system for making relatively "static" vector images with very good support for a lot of browsers (IE6 support, even). If you need user input, I think I would've tested out Paper and most likely ended up with that.
So basically: Raphaël for vector images that may be scaled and simple, dynamic images. Paper for animations and e.g. games.
If you have a similar situation on your site/application, I think it's perfectly reasonable not to support anything other than modern browsers, but you have to look at your own stats.
[EDIT] Slightly sharper eyes.
RaphaelJS has IE covered.
Wouldn't it be great if someone did all the RaphaelJS examples in PaperJS, and vice versa, so we could compare performance and ease of use?
var a = new Sprite();
var b = new Sprite();
b.x = 100;
a.rotation = 45;
Which ideally should rotate both a and b by 45 degrees clockwise, with b offset in the rotation around a's axis by 100 px.
All that aside, it does appear that in the newest version Grant has finally caught up to almost where my code was about a year ago, and since I haven't maintained the project for almost two years, that's saying a lot =) Great work Grant! If I had a serious HTML5 project, I'd just loooove to use your code for it =\ hah. Although I'm sure if one of those arises I could write something better in a few hours.
The trouble is, right now there is still nothing to be gained from writing something on a Canvas. It's too slow to play on an iphone, and there's no point in using it on a desktop when you can use Flash. And now anybody can release a game in html5 w/o any coding whatsoever, guaranteed. Grant: We are both pissing on the same lamppost in hopes of adding a tiny pile of sodium to it. Who gives a fck. Seriously, God Bless, just "rule the universe in HTML5". I only wrote my code a couple years ago to prove it was slower than the same thing in Flash. You want to make a life's work out of it? 3.2 major revs? Go ahead man.