Although the technical objections are largely obsolete, I think there is still a UX-based objection to auto-save. Other answers have alluded to the relationship between versioning and auto-save. @sova talks about them as alternatives, but I believe they are essential complements. Without versioning (or at least persistent, traditional undo), auto-save has an important potential downside.
In a document-based interaction model, all changes to a document are temporary until the document is saved. The ability to close without saving provides a course-grained undo capability, since the user can always revert to the last saved version. This form of undo has very poor usability compared to even CTRL-Z/-Y style undo/redo, but it still gives users a "panic button" safety net. Auto-save takes this option away from users. Without a compelling replacement, this arguably may be a net loss of data safety.
Google Docs and the new OS X Lion versioning feature provide an alternative, more powerful form of undo/redo based on a timeline, rather than the traditional command history stack. Both systems anchor versions to the timeline and allow the user to pull older state ahead into the present in whole or in part. This is vastly better than the single-version revert provided by a manual save document model. This removes the potential downside of auto-save.
In combination, auto-save and timeline-based version history provide a great UX. Auto-save without versioning is a mixed blessing.
@andrew-neely reminds me of another important case. Many business transactions have a significant transition between data entry and execution. The document model is inappropriate in those situations, and another metaphor must be used. However, it is still possible to protect against data loss.
For example, a system might be engineered to restore the state of the UI upon relaunch after a crash or power failure. The user can then choose to cancel or proceed with the transaction without repeating the data entry. Storing the state of the UI is a form of auto-save, but this would be transparent to the user.
A timeline-based history mechanism is also somewhat less appropriate for active editing interactions in this situation. The more traditional undo/redo may be better suited to a UX with short, transactional interactions. The short duration means that managing a command stack will be less of a burden, and the transactional nature means that reverting back past a transition point may not be possible in any case.
Versioning in a transactional system would still be possible, but it would take on a different character. Instead of displaying the full state of the transaction at each point during editing, it might focus on only persistent changes and present them as a sequence of state transitions in an audit log. A transaction is not so much an artifact in itself as a symbol of an ongoing process. A log of transitions better reflects this active workflow nature.