As many have noted, this approach makes it very difficult to create complex workflows, and tends to cause the same document to appear in multiple places--and in varying states of completion.
Now, this is not necessarily a bad thing; an interesting side effect of associating the ownership of a document with a specific app is that the latter takes full responsibility for managing it. On a desktop operating system, we have learned to subconsciously think of documents in terms of the kind of data they contain, and demand that apps be able to interoperate with file types that they do not directly own.
If you have ever tried to, say, open a Word document in Pages, only to find out that half your formatting was lost in the conversion, you know exactly what I mean. It would be impossible for Apple to be privy to every last nuance of a file format that Microsoft owns entirely, or for Microsoft to have to worry about the mistakes that a third party could make while attempting to read data that has been saved according to its proprietary scheme.
Despite its flaws, iOS's send-to functionality forces developers to come to grips with the fact that they are not merely "saving" a document, but passing it to another app. That in turn gives developers an opportunity to choose a neutral format that doesn't force the receiving app to make guesses about what the data means--and, in the process, enables the developers to explain to the user what, if any, features will be lost in the process.
Still, unless your needs are very simple, iOS's balkanized approach to document storage ends up causing the very same problems that it attempts to solve.
Thinking like people
This problem boils down to a simple issue: While the sandboxing model makes sense from a technical perspective and introduces a large number of advantages, it doesn't reflect the way people work.
If I think about the way I work, it's obvious that my activities revolve around the concept of projects. A project could be something as simple as this article, which consists of some text and a few images, or (at least in OS X) something as complex as an Xcode program, which may involve data generated by half a dozen apps.
Either way, it's a rare project that involves the use of a single app, particularly given that so many apps are becoming more and more specialized. At the same time, almost nothing that I do directly requires a file system. On a large project, I may use folders to compartmentalize data--say, to put all images in one place--but I do so only for convenience reasons, and would much rather leave that task to the operating system.
Sign up for Computerworld eNewsletters.