I'd say if you have the option to store images outside the database then do it - relational databases weren't designed for storing images, and although they can do it (BLOB fields etc) it causes all sorts of nasty headaches with performance / searches etc and is best avoided.
More cons than pros it seems. But as always, it comes back to the best tool for the job. If you have a very specific reason why you need to store the image in a database then do it (the author cites distributing it over several servers as a reason). But even then there are alternatives - I've used network filesystems to do just that.
One of the classic "right" applications where images should be stored in the database is when the filesystem overhead outweighs the database query overhead.
We built an image database for icons and "smilies" and other very small images. This site gets about 2,000,000 requests a day for these images. The database delivers them without blinking. The file system version was so overloaded that the consultant's answer to the problem was a $250,000 storage device to put a couple dozen spindles under the I/O.
We told the customer that we would do the project for free if performance did not improve to a satisfactory level (one of my designers was absolutely certain the database design would outperform the filesystem version). We were paid $50k for 2 weeks work and the customer was thrilled with the results.
It's all about what tools are appropriate for the application at hand.
TheWitt makes a very good point -- most RDBMS' have very advanced caching mechanisims and chances are will store the images cached in RAM (so it is very, very fast to pull out). Most web servers that I know of are pretty stupid when it comes to serving things like static HTML and dumb images -- it will continually pull them from disk even though they do not change.
Hopefully if Apache grows up (multithreaded, caching like that) those problems will be a part of the past. Until then, give your DB lots of RAM and you should be fine.