Whilst AIR makes it really easy for web developers to build and deploy cross OS desktop applications, it’s important to consider whether a desktop application is the most appropriate way for your target audience to access your RIA. It often takes some time to establish best practices as to when you should and shouldn’t use a new technology and with AIR it’s no different.
There will always be a place for fun, highly branded consumer applications on the desktop – of which Desktop Keeley still stands out from the crowd – but for the development of tools and applications that could be deployed either on the web or the desktop, it is important to consider how an AIR application will enhance the user experience and/or make the user of the application more productive.
Several customers have asked me whether Adobe has guidance on where AIR should be used – going through the documentation you can of course determine where AIR could be used, by understanding the features and APIs provided by the runtime; but could and should are two different things 🙂
I thought I’d have a go at writing a quick checklist of the questions you might ask when determining whether you should build your application on AIR (or determining whether there is benefit for both a web and desktop version, with enhanced features in the AIR application). Here’s what I came up with:
#1 Is the application likely to be used on a regular basis (daily)?
If yes, then access via desktop icon, start menu or launch upon login is more convenient than browser shortcut
#2 Is there potential for conflict between the application UI and that of the browser?
If yes, then native windows, native menus and custom application chrome improve user experience
#3 Does the user require access to the application or the associated data when offline?
If yes, then local filesystem access and SQLite database access provide the user with offline usage
#4 Does the user need to work with large volumes of data within the application?
If yes, then local filesystem access and SQLite database access can improve application performance, rather than relying upon remote data storage
#5 Does the data the user is working with change on a regular basis and is it important that the user is alerted to such changes?
If yes, then desktop notifications provide a convenient way to receive updates whilst the application is closed/minimised
#6 Is the user required to upload files or transfer data from other desktop applications?
If yes, then cut/paste from other desktop applications and drag/drop from the local filesystem makes the user more efficient
Obviously the more questions you answer yes to, the stronger the use case for deploying your application using AIR; although, just one or two initial features implemented in AIR could mean the world of difference in productivity for your user when compared with a browser-based application.
It is also important to remember that there are some AIR features that, if used inappropriately, may actually annoy your users or make them less productive – check out Serge’s post for advice on how to make sure that doesn’t happen.
If you come up with any more qualifying questions for whether a RIA should run on the desktop or you’ve built an AIR application that doesn’t fit with the above criteria I’d be interested to hear from you.
Andrew Shorten's Blog 
For me it comes down how I want the user to interact the program and not just a technical argument of AIR’s APIs. Though I would agree with the points you have made. Desktop applications allow you to interact more directly with a user. Though just because you can doesn’t mean you should as you noted with Serge’s post.
I’d say AIR applications are no different to “normal” desktop applications (with in the limits of the AIR runtime). So really this is a question should you be creating a desktop application, a web application, or both? I think there is still more debate to be had on this matter but at the moment I’d say people by default create web applications without thinking would this idea be more suited in the desktop.
If the application requires window management (docking, undocking, persisting window locations and sizes, etc…) then AIR is pretty much the only option.
However the requirement for users to have system privileges to install AIR applications is a factor that can make web applications much more attractive in enterprise environments where users typically don’t have such privs.
Another downside of AIR (and of desktop applications in general) is the implicit requirement for version maintenance. With a web application you have total control over the version of your application that your users run. With a desktop application controlling the version that your users run is much more of a challenge. While AIR has its “update framework” which helps, in the real world and especially in enterprise environments you’re probably going to need to support multiple versions of the client simultaneously. This might mean that you need to version your service layer. This creates additional s/w complexity and increased testing cost.