The default was 'store stuff in database' because the original version (aD's, that is) stored everything in the database. This is mainly for backwards compatibility reasons, although there are a lot that changed in the port that there is really no need to maintain backward compatibility.
Storing stuff on the database also makes it easier to backup -- you only need a database dump. It seems reasonable that the default behavior allows fewer ways to mess up. Storing stuff on the filesystem is done mainly for performance reasons (probably why dotLRN decided to default storage on the filesystem -- I'm just guessing). But to backup your file storage instance in this mode of storage, you need a database dump AND a copy of the files that the content repository created.
As for whether to take it seriously, note that the parameter is consulted only when a new file/version is uploaded. You can change the parameter even after files are already in the content repository, but from then on, the storage mechanism will change. Files will still be read/downladed ok, but backing up the contents of your file storage becomes really complicated because some of your files are in the database and the others are in the filesystem. Hence it is a good idea to change the parameter only at package instance creation and before files are uploaded to file storage.
Yes, file storage should be well documented (I thought I added a note about the storage mechanism parameter in the docs, but perhaps not). We could say the same for almost all packages in OACS -- it will take a while.
