This is all black magic to non-DBAs. It is arcane. When I use a file system for storing blobs -- as simple files -- I don't need a DBA. Back in the early years of
modern computers, you needed a file system administrator, for more-or-less the same reasons that you need a DBA now: file systems were fragile. Now, file systems are one of the most reliable parts of computer systems: they Just Work
That's a dangerous and unfounded assumption.
Filesystems are reliable only at the metadata level: if you yank the cord, the system will still boot afterwards. You won't end up with a filesystem doesn't mount, or where the system manages to mix two files up in such a way that writing to one damages another. But that doesn't guarantee much about your precious data. A half written file will be half written, or even corrupted, unless precautions are taken. And those precautions (in which order to write, how to ensure your data is safe, when to fsync) are just as arcane as the database stuff, if not more. Because databases deal with that crap internally and give you a much simplified interface.
Take for instance a simple exercise: writing .jpg files with product images. But just because the file is there doesn't mean it's good, if you crash at the wrong time you might have half an image, or something that seems to be the file, but is really full of junk inside. So you need some way to determine when a file is really fully written. So now you're keeping a list of checksums which is prone to the same corruption, or doing durable renames, which is arcane magic, and still goes wrong when filesystem developers find another way to optimize while following the very lax spec (see the ext4 debacle)