Performance on the Web isn't RAM-bound at this time, unless you're running on a Raspberry Pi or somethin. Network performance is a much stronger limiting factor, which is why protocols like HTTP/2 are being made in the first place.
I'm also skeptical that sprites must necessarily be significantly more demanding memory-wise than smaller images. Implementations may vary, but at least in current browsers, when you make an Image tag/object with the same source as one you've already loaded, the second one loads instantly. This at least makes it appear that both image tags are getting some kind of lightweight view into the same image data -maybe just a pointer to the same bucket of bits- as opposed to having to re-download and/or re-copy the image data for each instance.
The memory usage of CSS sprites (which are implemented as css background images rather than Image objects) was definitely an issue a couple of years back. Inlining the images as base64 data uris seems much better.
I think he means the empty space that is demanded by sprites, in memory it occupies space as a bitmap. If you use a smart sprite builder that optimizes stacking, it will probably be less than 10% overhead, but still relevant.
I'm also skeptical that sprites must necessarily be significantly more demanding memory-wise than smaller images. Implementations may vary, but at least in current browsers, when you make an Image tag/object with the same source as one you've already loaded, the second one loads instantly. This at least makes it appear that both image tags are getting some kind of lightweight view into the same image data -maybe just a pointer to the same bucket of bits- as opposed to having to re-download and/or re-copy the image data for each instance.