Fuzzy reasons abound, but you do occasionally see this. One major often-complete-blocker that I've seen though has been ungood rendering, so results aren't always identical on all devices. You can't really rely on the device's possibly-weird implementation (who knows what the OEM did to it)(except on iThings probably), so you're forced to bundle an svg renderer that works reliably on all devices and has consistent behavior, and good luck finding a high quality lib that does that[1]. And, to be friendly to the designers, it has to be reasonably full-featured.
I've made few apps and so far nobody cared about it. I thought that hand tweaking was about 16x16 icons, but now we are using 1024x1024 icons sometimes, there's no reason to tweak anything there, really. Actually it was the other way around: I wrote some scripts which rendered SVG into multiple PNGs and I think that almost everyone does the same.
SVG stadnardisation and support is growing fast, notably because it is now part of HTML5 and has strong support in browsers, which are the most active software development needed for all kinds of apps.
SVG includes many tests to assert the conformance and is one of the best graphic standard in terms of standardization with very precise requirements. It's in fact easy to get the expected results on wide ranges of devices, and implementations are now very performant. they are implemented as reusable opensource libraries or directly now in core services of most OS distributions, and even part of mobile platforms. The hardware is now optimized to support almost all SVG graphic primitives. The standard is not born from nowhere, it has inherited the best practices initiated earlier in PostScript then OpenGL, DirectX, X11 and similar APIs, and references other related technologies that are also standardized: Unicode, OpenType, IEC color spaces. There are still ways to extend it, but the SVG standard defines the requirements needed to support many devices, small or large.
Only very old implementations will suffer from some quirks due to absence of support of newer features, but the graphic will still render correctly provided they followed the mandatory conformance rules for each version.
Remeber that SVG extensions are widely upward compatible: newer renderers will support all graphics built for conforming renderers based on older versions.
Note that SVG is not designed to get exactly equivalent results but results that are suitable for use on each device. This is absolutely not the case for bitmap graphics which are extremely hard to adapt, and waste lot of bandwidth.
The next step for SVG will be to be a bit less verbose, suing another base syntax than XML: JSON seems to be the best candidate as it offers significant performance improvements to XML parsers: this will appear because now SVG is standardized primarily not for its syntax but for its DOM and API, just like HTML now and more recently as well with CSS (which is also used by SVG).
And more impoprtantly the SVG standard is open, allowing all kinds of experimentations and implementations. No new feature appears in the standard before there's already been experimentations.
The only few things that SVG do not support completely for now:
* fine tuning fonts to handle more semantics and typographical effects
* better support to render on non-additive color spaces (SVG still depends to much on sRVG which does not print very well, and new display technologies are now using more than 3 color planes to extend their gamut); colorspace transforms, and masks are still better supported in PostScript.
* support for 3D rendering is still in alpha stage, but will come sooner or later.
* support for splines may later add other curves than just quadratic or cubic Beziers, and elliptical arcs: hyperbolic, sinusoidal, and other parametric curves should appear, with their own rules for their subsampling decompositions to match the expected resolutions on target devices
* lighting models are still too simple. But the OpenGL standard already drives what will appear.
* support for texels should also come for 3D rendering, including mipmaps and synthetic/parametric mipmaps
* integration of videos with SVG animations is still a challenge; given the neeed to also synchronize in time with audio, users events or scenarios for gameplay.
The HTML Canvas will drive the needs, as well as other W3C specifications related to accessibility, internationalization, matching user preferences. You cannot do the same thing with "stupid" bitmap graphics. In fact the birmap graphics will be internally converted to vector graphics for better rendering (this is already what printer drivers are doing to improve their results, you cannot do that only by subsampling, bicubic interpolations: you need geometric transforms, notably for adapting texts or symbolic designs such as maps): the individual "pixels" in bitmaps are really stupid objects that do not properly handle how they are geometrically linked to their surrounding pixels: there's a need to contextually hide or show some details, or improve some of them, vector fonts for Opentype are perfect examples of that need.
It definitely is improving, and it's fantastic to see the progress. I really enjoy SVG assets, and I'd love to see them mostly take over (obviously they'll never be 100%, nor should they).
But that still means it's years away from widespread support, because large companies can't rely on it for large user-bases, and feature-sets are still pretty widely varying in my experience. Some support animations, some complex gradients and masking, and huge variance in text rendering (which is absolutely essential to finely crafted images) cripples some of the most-valuable use-cases (internationalized images without making dozens or hundreds of near-duplicates).
It's just not there yet. I hope it gets there, but there are significant hurdles that don't seem to be getting a lot of attention.
Sure. So hand-tweak the SVG files per density that you need custom-handled. Like you already do for images / when exporting images. Same difference....
... except now you need to do it on the device too, to make sure it renders identically there. Otherwise the same problem!
---
For very small images it doesn't matter / png may be smaller, but small images with that quality don't typically add up to hundreds of megabytes.
[1]: but if you know of one, I'd love to use it!