I suspect there's not much to gain by caching images in the browser: If you're looking at a page full of comments with hundreds of avatars, chances are the next page is going to make you load hundreds more that you haven't seen already: There is a very large number of commenters, and you probably won't see the same people on every page.
The demo is right: they ask for 300 different images (as in, different URLs), and their packager makes it faster.
Also, how would you inline include images? Using base 64 in the image tag?
The demo is pretty unfair. If you want to package lots of the same image, you just use it and let cache control do its job. If you want to package lots of different images, you should use a big sprite (again, server-side packaging without any js). If you want to make image loading look slow, do what they did in the demo.
There are a bunch of images that can get repeated across pages for a web site that are completely vital to cache. Think rounded corner images or background images or icons.
Lazy loading seems more efficient to me for this particular use.
They do plenty to cache images (including the digg dude). This is about the first load. Yahoo has some report showing that data is uncached quite a bit of the time, even when sending the appropriate headers.
It seems like you'd be better off with a pre-processor server-side to inline include CSS, Javascript and images, then send the resulting page back for rendering. Javascript isn't nearly as fast as my C++-based templating engine...
edit to add: Also, don't discount the big savings you can get from "302 Not Modified" return statuses, especially on big chunks of content like images. The DUI.Stream image demo they had would get smoked by the 'dumb' version if they allowed the browser to cache the digg dude.