My reading of this is that the Chrome Web Store is where apps are listed and users authorize them, but not necessarily that the app has to run in a web browser. The user could authorize the app by "installing" it through the Chrome Web Store but download/use it from a totally different channel.
PS: I work at Google but don't have any inside info on this.
I understand that. There's no way to have the web store install a native app.
But once you have "installed" the web app, how would the API server have any idea whether a Google Drive API request was coming from a web server, some JavaScript running in a web browser, an Android app, or a remote island in the Pacific that has no electricity via the "IP over Avian Carriers" protocol? It's just HTTP requests with some authorization headers that tie it to your app's identity.
Google Drive synchs to your local hard drive, and thus works with all of your apps. (Right?)
It ALSO has a Chrome interface to be clever. Picture opening a 1,000 page PDF. If the Chrome PDF Viewer knows how to fetch individual pages on demand, do searches on the server side, etc., it could be very nice for quick previews, etc.
Also, it works great for one content creator (who has the app on the desktop), and a bunch of content viewers (and commenters) who just need Chrome.
I think its a pretty stupid move. If they really want developers to flock to Google drive, they should not limit the api to their little corner of the world. I'm guessing that they are going to open it to all apps eventually.
PS: Yes, I work on the SkyDrive developer platform. It doesn't change the truth.