Ideally animated SVG should be self-contained as an image format, and easily injected into an existing page, but it's not. It needs dependencies to animate, either CSS (which is a bit fiddly) or a javascript lib.
GIF is easily injectable, easy to update, which allows a nice, quick iterative update cycle. It's also compatible across the board and pretty future-proof at the moment.
Well, SMIL does exactly that but has lost traction and has been deprecated in favor of CSS and JS animations. Support has actually been removed in Chrome or will be removed in the near future.
AFAIK you can include Javascript and CSS inside an SVG image, but it's common practise not to do that. I don't know why, but there's no reason not to do it.
JavaScript isn't executed if you use the SVG via `<img>` or CSS, so it's not useful in those contexts (you'd have to include via `<object>` or `<iframe>`).
So far as why it's not commonly used elsewhere, unless you've programatically constructed the whole image already, it's rather a pain to animate SVG. The markup spit out by authoring tools for any non-trivial image tends to lack the structure you'd want for animation. I suspect that's why we see JavaScript APIs like d3 used instead of embedded JS.
Authoring tool could spit out JS themselves, of course, but in all the contexts where JS executes you can basically substitute a full HTML document, and that will be more flexible and performant (SVG is not well optimized in most browsers, as the OP notes.)
GIF is easily injectable, easy to update, which allows a nice, quick iterative update cycle. It's also compatible across the board and pretty future-proof at the moment.
SVG animations could work better by containing the code within the SVG file itself. Not sure how compatible this would be, but something to look into. http://stackoverflow.com/questions/5378559/including-javascr...