I'd prefer to have stuck with SVG had it not been for the I'd collision thing, so with one of these tools in our chain we just might do that.
We use some server side code to recolor svg's on the fly with caching headers so they aren't requested all the time, mostly through img tags since we moved from PNG to SVG, its just works.
Using inline SVGs also reduces our caching complexity _dramatically_. I'm now "just" caching markup with no binary asset caching.
Moving forward I'm going to experiment with
At least SVG as images can be resized so you only need one asset regardless of size, color manipulation then is the issue, but since SVG is just xml it pretty easy to do server side and again the browser will handle caching just like any other image.
So we jumped to PNGs (like 2 weeks ago, fyi). Now that we (know about, and) can use one of the svg cleaners, we'll switch to that and go back to inline SVGs.
PNGs were always seen as inferior. We don't want extra requests to load them - our app is very sensitive to the number of requests we make - we're importing them as datastrings even.
Anyway, the choice was made. Now we're 90% likely to revert to inlining SVGs with some kind of cleaner in the pipeline. Please don't lose any sleep over it. We'll be just fine.