As the original author of the IDE, I can understand why you would be unclear on the future of the IDE. Rather than say it has been deprecated I would say that it has been put in maintenance only mode, but IS supported. That is to say, that with each release of the platform, the next being Winter '14, the IDE will be updated so that the API endpoint of the SOAP API used by the IDE is current.
The IDE uses a combination of SOAP and Metadata APIs and to gain access to the most recently exposed metadata, this endpoint update, and re-compiling needs to occur. But, that is the extent of support that we are committing to with the current IDE code base.
The long term strategy is as described above. We have moved resource from adding new features to the IDE to developing an API who sole purpose is to support tooling. You can see the progress of the tooling API in the Developer Console, which is the first place that this API is being put to work. Once the tooling API has reached a level of functionality, we will revisit an Eclipse plugin.
The IDE was built by salesforce Developer Evangelism for the reasons that you excellently point out above. It was built before we released a Metadata API even, mostly to gain the usefulness of an IDE, but the main reason was so that the developer had access to the built in source code control, something that is terribly important for real development and governance.
Due to the popularity and adoption by the developer community, the project was "forced" upon the R&D side of the house so that it could be properly supported and maintained. The code behind the IDE has evolved organically and over a lengthy enough period of time that the entire underlying implementation has rightly been called into question. Newer APIs exist that can/will be used in conjunction with the tooling API to deliver a better performing, less chatty IDE. Included in this is something akin to a grammer for proper code assist and refactoring, replacing the current polling mechanism with a streaming API mechanism and a better Visualforce editor.
The Force.com service is unique, so while we can borrow a lot of techniques and approaches, some aspects of this just have needed to be invented. Hopefully this demonstrates our commitment to the IDE and other tools like Mavens Mate and BrainEngine
EDIT: On September 17, 2013 the DeveloperForce blogs came out with the following article. Cliff notes:
- We will be updating the plugin to work with the latest versions of Eclipse and Java shortly after the Winter ’14 release.
- We have been finishing up the Tooling API to prepare for the more complete refactoring which is now in flight.
After the refactor:
- Dynamic Metadata API: No more need to upgrade the plugin every release to get the latest metadata API. Latest and greatest available at all times.
- oAuth: No more need to reset a security token and update projects with new credentials. oAuth authentication will keep your plugin authenticated to an instance until you tell it you don’t want to be authenticated anymore. Especially useful for those of you with admins requiring monthly password resets.
- Code Completion: The Tooling API provides symbol tables for an org, which will be used to offer code completion. Developer Console offers this today; rebuilding with the Tooling API will allow the plugin to offer it too.
- Better Save Process: The Tooling API provides a mechanism for saving code artifacts more directly than the metadata API, providing a much less unwieldy experience.
- Plugin-only: The current approach of offering a bundled exe to install both Eclipse and the Force.com IDE plugin. We’ll be all plugin, all the time.
EDIT: On July 1st, 2014, the Force.com IDE Core has officially gone open source on GitHub. The community can now help maintain it.