I got burnt very badly when I inherited a project that was storing images inside the WAR directory. First software upgrade, and "BAM!" All the images are gone.
Besides, you
can't upload files into a WAR unless it's an exploded WAR. And exploded WARs actually aren't part of the
J2EE architecture. They're a "feature" of some, but not all J2EE appservers. In fact, while some versions of Tomcat would automatically explode WAR files, some don't appear to, and it's a configurable option on most of the recent ones, I think.
It can be a problem, however, using an external data directory, since that codes a dependency on your server's filesystem into the app. A good way of getting around that is to define the directory path as a web.xml resource and look it up via JNDI. In Tomcat, you can override the default value in web.xml without actually having to modify web.xml itself. Although even that's better than having to change source code and recompile.
Blob avoidance is one of those Urban Legends. I wouldn't just assume that because someone says so that they're always going to be a bad solution, but rather do an app-specific case study. Obviously, as always, abstracting your storage mechanism will help in switching mechanisms once you find which way you want to go. And change that mechanism later, if it proves profitable.
Oracle 11 was claiming that database accesses were faster than file accesses, for example. YMMV.
One thing I do know from my own project. It can be a real pain when the images are in the filesystem when you're using the database on a separate
test machine.