An analogy is the folders view of e-mail, which was standard until gmail came along. You'd save different mails in different folders depending on its purpose or origin. But gmail automates the classification based on contents (you can still step in and do it manually): an email can belong to several folders but needn't be physically copied among each.
Such a thing would be a great way to handle files. I may be working on a document (or a set of notes) as a part of two projects, and depending on which project I am looking at, I want a different set of files to be visible, including that document. But I don't want two copies of that document. When I make changes, I want the changes to be visible in both places. (Yes, symlinks can do that, but maintaining symlinks is a bit of a pain. And it would be nice if the computer could automatically say "These are the other documents on your system that could possibly be relevant to what you are doing...")
But to *really* push the envelope, existing filesystems like ext3 aren't enough, either. And putting a database/search-tool on top of the filesystem is an ugly hack.
The fear is that moving to the "search-centric model" using a filesystem that is built on the "files and folders way of thinking" will lead to huge confusion, in the short term at least.