This is something that has been discussed before, in fact it’s a use case that I’ve previously explained. There is no disagreement that it would be useful, but the devil is in the details.
Some platforms don’t provide general-purpose FS access as @Libertardian correctly points out, but I don’t think that that’s an actual problem. Just because some platforms don’t have {a camera, geolocation, a colour screen, etc.} doesn’t mean we can’t have a given feature. It just means that its behaviour needs to be defined when it can’t physically be supported. (In this case, you probably get nothing or some form of disabled affordance — and that’s okay.)
The problems have more to do with how to scale it both over time and over number of files, without introducing security issues, and while remaining usable.
Let us start small and assume this only works on a file by file case, without handling the directory issue (which as @Libertardian also points out, is likely to confuse people on OSX for some file types). The issue is of extension over time: if I edit my text file using this mechanism and later return to the app, does it automatically have access to that file again? Can I reasonably expect the app’s state to just be restored with the file open and ready to be written?
If the answer is no, there’s a bit of a usability issue (but not a huge one in many cases). If the answer is yes, the situation is more complicated. Maybe I gave access to a web app to write some of my HTML files with, but after a while I realise that they’re doing something I don’t like. I’m not talking about something outright malicious (though that could be the case), just something I’m not happy about. Maybe they add a little tracking code to get an idea of how many people visit pages made with their tool. Maybe they just add a comment pointing to their site. Nothing illegal, but I want them to stop. The problem is: whenever I visit their site (say, because it has great documentation) they regain writing rights to those files and automatically add those annoying comments. This means that users need a clear and simple way in the browser UI to know that a given web app has access to a given set of files (and ways of revoking that). Honestly, I have no idea how to do that cleanly.
The issue of extension over number of files is also annoying. For an image editor in many cases you can probably work fine accessing images one by one (and even then, it depends on the workflow). For a text editor in a great majority of cases you often need access to an entire subdirectory in order to be useful. This could be done: just let people pick a directory, and expose all the files in that. But naturally this increases the danger, and increases the complexity of exposing the user’s actions safely.
Maybe the right approach is to start from a minimal option that can only do one file and only for the lifetime of the given document hosting it. And if that works, build atop it to add more capabilities. But the question is: would something this limited be enough for the functionality to prove useful and take off?
