Depending on the software, the information captured needs to be organized in one way or another. Users don't just supply input only to be dumped in a large holding bin. The user doesn't want to sift through their information when they actually need to find something. Another reason users want their information organized, probably according to a schema of their own creation, is for when they don't know what they're looking for exactly. There will come a time, when you have a flash, a sudden recollection, or partial memory of something more complete. You know it exists, you just need to come across it to bring it to the forefront of your memory. In these situations of "I don't know what I'm looking for", we browse our stored information. How we browse, depends on how we organize. But organizing isn't just some trivial activity. Depending on the organizational facilities we've provided to the user, they just might overwhelm themselves.
Usually what the user wants to store isn't complex. At least, not complex enough to justify introducing twenty different ways to organize something simple. Because, the odds are, users will explore everything you provide them, and agonize which organizational approach is the best one. Which one best fits their data is the one that allows them to quickly capture their data without it getting lost. Why would we want twenty different ways to organize information? These amount to either different features, or different dimensions of the same feature — all of which need implementation and maintenance effort by the software development team. What does this ultimately provide to the user in terms of raw value? Probably not much. This is really geared more toward capturing a larger user base. With a single user in mind, adding more organizational capabilities makes the life of the user disorganized.
Taking all of this into consideration, let's think about the common organizational unit in all information systems — the category. Imagine the user that is only peripherally concerned with organizing their information. They may or may not want to attach a category to their information. With this user, we've managed to stay out of their way. Now imagine the user who borderline-obsesses about about how their information is stored. We've given this particular flavor of user the tools necessary to devise a scheme that we fit whatever level of complexity they feel is necessary. And that's where I think the focus should be on the software development end of the information organization problem. We should be providing users with basic tools, not our interpretations of how we feel information ought to be arranged.