This blog post shows the results of a performance comparison of different session storage engines with Magento and they seem to have concluded that up to about 75 concurrent users there isn't really a performance difference between them.
I think that at these levels (they had about 5 transactions a second, which would be about 430k hits over a 12 hour period) the overhead in everything else dominates the performance numbers you see since file/DB/Memcache/Redis will all happily handle the traffic without breaking a sweat if used properly.
That leaves other factors such as scalability, reliability and security.
I'd first like to say that anything that compromises your file storage will also likely compromise anything else since an attacker can then just modify your application code or at the very least discover keys and storage access protocols/credentials even if they have read-only access. File storage will work well for a low volume site, is easy to set up and is easy to reason about. As much as you say you hit the disk, a DB read will also hit disk and if the DB can cache it, your OS will also likely have cached the session file. Also, its one file read, and your file system is brilliant at getting to it if you already know its name. If you're using PHP, do you know how many file reads the system has to do just to serve your application? The downside is that you can't go too far as you will quickly reach the limit of the number of files you can keep on a single disk.
Memcache is relatively fast and if you're considering Memcache class solutions more broadly (Redis, etc) there are some that will even promise persistence with in memory reads for speed so you get the most of both worlds. They are also relatively simple to reason about and the key-value nature of sessions is exactly what these have been designed to do. Do you know how much you would have to put into a session to fill one of these up? Either, way, all of your options will force you to compromise if you reach their capacity. Disks fill up with files (number and size factor in here), cache stores fill up in capacity and databases have limited numbers of rows and the same disk capacity limits as the file approach. Also, these systems are only distributed if you run them in a distributed fashion. Most work just fine with a single server setup. If you distribute them then you probably already have distributed web servers / database servers etc so your distributed system problems certainly won't be appearing from your session storage choice. However, when you want 10x the traffic/capacity etc, getting there is much more natural with this than it is with the file storage scheme. Some key/value stores will also allow you to conduct simple analyses of the session data relatively easily but most won't get you anywhere near what SQL can do.
I'm not sure why you propose that database may be more reliable than the other options, but I get the appeal of the database since your PHP application probably already makes use of it. This means you don't add another server dependency and you can probably reuse the same connection you use to fetch session data to get user data so you don't have to establish one for data, one for Memcache, etc. If you index the table well, it will also perform reasonably fast and provides pretty simple semantics you already familiar with for reaping old sessions or even analyzing session data (I'm not sure why you would want to and if you aren't either, this probably doesn't matter so much). Scaling to massive scales isn't as trivial as with something like Redis, but going from one PHP server to two both accessing the same DB is pretty simple.
I think this choice isn't so important in the beginning. Each approach has challenges and advantages and things you have to think about. Generally speaking, you can probably get away with just using the defaults of PHP/whatever framework you use or even just the easiest thing to get going with. If the choice turns out to be bad later on, your performance analytics will tell you and you will be armed with the data you need to make the appropriate choices given the specific nature of the traffic you get. Up front, all you can reasonably have is general speculation.
