The problem is not the viewing, but editing. When you say "Open In Photoshop" does this mean you can make changes and then save the "file"? What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Those operations are no longer just operating on a single file any more. From the perspective of a security system implementor, how can you understand such intent from sequences of raw POSIX filesystem calls -- because that is all the sandbox enforcement code in the OS kernel gets to see and approve or deny.

For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory.

The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.