The most obvious is to eliminate a dependency on a local file system. If you ever need to move to another host, with a potentially different file system layout, or worse, different path syntax, you will need to rebuild the paths in your database.

In my case, I have media coming in that I have to store. If I had to invent file names for the incoming data, write the file, store the name in the database, it would not be as convenient as simply dropping the media into the DB with autoincrementing of the int ID.

Another convenience is that all data access occurs in SQL. Thus, when I wish to construct an HTML page, I can grab the HTML, and images in one SQL query, then feed the page down. This is more significant given that the SQL and WWW hosts are different.

Another, seemingly silly, reason to prefer the table to the file system is the clustering cost on some lesser operating systems. The waste that can occur with many small binary images can add up. The table eliminates most of the waste.

On the DOWN side, you can easily and quickly run into file size limits. For instance, Linux limits you to 2GB files currently, which means that your tables are limited to 2GB, which means storing MPEG movies in a table is probably a bad idea. It also means that a single table would also make a bad image library. Plus, it is sometimes VERY convenient to have your media on the local disk for easy viewing and modification.

Nuances, I will grant you.