Definitely use a file store, whether that's a classic CDN, a cloudy one, or a roll-your-own. I also wouldn't bother storing all 5 image sizes. Create the scaled images on the fly, at first access (i.e. if the DB query for a particular image and size returns NULL for the URL, scale the larger image down, and return the newly created URL, then store it for future references).
Don't bother too much about hard drives. There's already a very effective file cache in every relevant OS, and you're going to be hard-pressed to beat that. Furthermore, you'd planning to service a million users. You can quote storage at a reasonable $1.00 per user and have plenty of money to play with.
Don't worry about the URL pretty-ness. Our filestore is known as download.<OurCompanyName>.com, even though it's actually hosted by a well-known CDN company.
Yes. Definitely valid advice. CSS classes, for the most part, should not be tied directly to what they look like. Tie them, instead, to what they mean.
If you're using .blue to provide emphasis, and your site design changes so that you no longer want your emphasis to be blue, then you have a disconnect between the display of the element, and the class name.
If, instead, you used .emphasize, you could change the color in the CSS, and the HTML attribute would still be meaningful. You get the change without having to touch the HTML (or, in this case, you could style the em tag, and get even better semantics in the HTML).
In addition, it makes your CSS more readable. When you're changing .blue, it's not obvious what elements on your page you're changing. But if you're changing .emphasize or .pull-quote, you can immediately tell.
There are instances when non-semantic class names are unavoidable, but this is mostly when creating generic layout. Things like column or column-left or half or third are necessary in grid-based layouts.
So, my opinion is that layout doesn't need to be semantic, and usually won't be. But content should definitely be semantic. Ask yourself what your content is, and make the class name represent that, so it can be used in a meaningful way.
Best Answer
Don't worry about the scaling (most browsers will make scaled images look just fine, in my experience), worry about the size of the payload you've sent to the end-user.
Sure, you could argue that you're only wasting a tiny amount of bandwidth on both ends for those extra pixels you're sending with no intention of using, but there's a time cost too.
For every image you send at a size that's above what's needed you add a tiny bit of delay to the page load for your user. For websites wtih only a couple of images this won't be an issue, but for a site with a large number of supporting assets you'll start to add noticeable delay, and delay will cost you money.
Also, with regards to the tiny bandwidth cost, as your site's traffic goes up, so will the tiny bandwidth cost.
So, save your company money and spend the 30 seconds you'll need to re-size the image yourself! :)