Each time I venture to do some mid size and enterprise consulting, there is always the question of using SharePoint as a replacement for File Shares, or the typical Z: or G: drive mapped in an enterprise. Now, joelo has added some more more discussion in his File Servers and SharePoint Doc Libraries entry. I just wanted to add some more caveats where SharePoint simply may not work as well, and places/reasons where I recommend SharePoint 200%.

Potential Problem Areas [not addressed before]

1. Long Paths – WebDav has a limit of 260 chars, and so does MOSS/WSS [or less]. I can’t seem to find any references for 2007 on Technet so here is an old one, but you can run a quick test… create "Really Long Folder Name 123456" 8 times and an error will occur. Such a long pathname is really hard to find, but it is still possible [although many other systems will have the same issue]. Recommendation: check paths/lengths before migrating.
2. Weird files with inter-file references – the most common problem here includes Excel spreadsheets that are typically peppered with references to data stored in other excel files, or help-style references to other documents. This will be difficult to migrate into SharePoint [or other system], as the references typically use a absolute file handle. If you migrate these into SharePoint.. expect to make a lot of modifications, and make sure you add proper clean-up time in your project if you discover these. Recommendation: you will have to clean up no matter what solution you choose, this is a brittle design anyway.
3. Weird file names – Infrequently users will have filenames that are like test…txt or test#%.txt as a requirement of some application, or as part of a file naming standard. All these will be a no-no [there is an official list of disallowed characters in SPS 2003 admin guide if I recall properly]. Also folders and file names must be 128 characters and less. Recommendation: check file names, and figure out a decent way of substituting these characters without making an embarrassing mistake.
4. Weird applications that do some crazy file locking a la Access – obviously Access is just one of the applications that depends on the file system beyond just storage [I guess others would include some engineering documents, or streaming audio]. These will simply not benefit from SharePoint because they are specifically dependent on the OS file system to perform [e.g. access creates lock files, streaming audio works better when only chunks of file are sent]. For these types of files, I’d recommend using a specific application server, or retain a standard file share.
5. Weird applications that use the files and create files – occasionally, the files that are created by users are also reused by some other enterprise applications. Make sure and test that the 3rd party application can actually work with SharePoint as part of your project plan.
6. Security – SharePoint security is only different than what you’re used to in file system. You can’t really have a "deny", as well as some other options that are typically ignored. If you happen to utilize one of those security options, you must rethink. Recommendation: check if security can be re-factored or updated to fit SharePoint, otherwise keep SharePoint.

Super-duper benefits of using SharePoint included in my top 5 benefits are below. Just one note of advice. When planning on using these features, plan on training your users on how to leverage these. It should not take more than a 1-2 hour session [in the area of file usage]. 

1. Versioning, publishing, workflow – especially useful when working in a group of people. Every place that uses standard file system always runs into file editing collisions [multiple simultaneous edits], or ends up with silly file names ["proposal version 1 tom.doc", "proposal Mary v2 -review.doc"] this just leads to confusion and long term disaster. Recommendation: use SharePoint [MOSS if workflow needed], deploy Versioning [and some pruning]. Savings: 2-3 hours a week/person in reconciliation, approval.
2. Backup/Recycle bin – typical problem with a standard file share, or even a local My Documents folder are accidental deletes of files. It takes 3 days for someone to realize it was deleted, and then a week to get it back. With SharePoint, you get it back immediately [or fairly quickly, even if you deleted it from recycle bin and have to ask an admin], most likely there is no backup when you save files locally. Recommendation: use OOB SharePoint [WSS works]. Savings: enormous if accidental deletion occurs.
3. Access – when storing files in a share, you can typically only access it from few computers, then you have to do some crazy tricks to copy the files to open them at home, or even a different office. With SharePoint, files are available from desktop, intranet, or even the extranet if your company provides this feature. Recommendation: OOB SharePoint [WSS works]+ extranet. Savings: 1-2 hours a week/person in synchronization.
4. Metadata – this is not necessarily obvious to many people that do not deal with metadata, but there is always a ton of implicit metadata to be found, even in a straight file system. First you start off with a folder/directory structure [people can store proposals, separate from invoices, separate from documentation, etc] and moving onto file names ["proposal for XYZ LA branch for 2006.doc"]. Eventually, there are 300 folders with 1 document in each folder, not an optimal solution for finding a document. It is so much easier to deal with the documents when you can see a collection of 10-200 documents and use metadata columns to browse/search the documents instead. Document folders could be used as security or team containers. And when the number of documents is too large, create more folders. Recommendation: rethink your organization of documents, use metadata [including site columns, preferably], roll out WSS. Savings: better reuse of data, impacts search. Cons: this, if decided by committee, may take a long time to implement.
5. Search – for those people that have ever tried to find a file on a file share, you know it’s like looking for a needle in a haystack. Whether is it 100 MB or 20 GB, it is almost always a very lengthy search [and typically locks up just about every resource available]. With SharePoint it is instantaneous, filtered, ranked and includes full text of the documents. Recommendation: use SharePoint [MOSS]. Savings: 1-3 hours a week per knowledge worker.

Now, the final question/problem I would have: shell integration [also, why does Windows XP and Vista in general shy away from Tree display?]. Is the ball dropped due to the bundling problem? SharePoint 2001 had a much better integration story with the desktop [property inspection, check-in/check-out, etc.] now it is gone….

Whenever considering SharePoint as file storage, the benefits are clearly enormous, with straight out-of-the box implementations, but keep in mind that there are these few scenarios where you may run into some difficulties, and check for these before ruining your reputation. Make sure your knowledge workers are trained to reap the benefits which could be 5+ hours a week.