I would assume if I had a vector of Images all using the same image that the QuadBatch.addImage() call would simply be pulling the x, y, etc values off the Image. So if img1 and img2 share the same image:
That's correct, when an image is added to the batch, its transform information is used. So there's a choice here between using image objects to store the transform information, or keeping single instances of everything, and storing seperate transform data.
I can't imagine having one Image and a vector of positions is significantly different memory wise than a vector of Images
The answer to your question, would be to test both and profile the memory usage. I would wager that actually the difference will be significant, if you are starting to use large number of images (and this is the situation where this strategy would become an optimization, rather than a pain to code with!). If you need to render 1,000 bullets on screen - a 1000 element vector containing some kind of structure that just records basic transform information vs 1000 starling images (descended from Quad descended from DisplayObject) - there ought to be a saving both in memory (and in performance when instantiating that memory).
Of course, you don't have to use quadbatch at all - you could just use the display list (though quadbatching everything might save you some performance from display tree iteration). It all depends on your use case. If you didn't have to compute a lot of transforms, then a quadbatch, with single image instances would be a no brainer. If displaylist performs fine- use it. If you are doing something graphically intense (huge number of objects) and performance is struggling, then you will need to look at lower level optimizations (look at the various starling particle extensions for examples of this). It's in those cases that people might opt for bypassing the display list, just having a list of image objects, and applying transformations themselves, before batching everything that needs drawing.
"significantly different" is all relative. If you don't need much performance, small differences probably won't matter - if you do, then they stack up!