An extract from Mike Cohn’s User Stories Applied concerns me because I don’t know what artifacts I have available when maintaining the software.
Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. Stories, on the other hand, are not intended to outlive the iteration in which they are added to the software.
After the software is build how do I maintain the software? How do a find out what the system should do if the story has been ripped up? If the story is not intended to outlive the iteration, what about the acceptance tests? If a user story changes surely I would use the existing story and acceptance tests to understand the impact of the change. The code can not be the only documentation for a system as only a small part of the team (the developers) can understand the code.
One of my biggest concerns about agile is that it is all about developing software are not about maintaining software; the maintenance cost over the life time of a piece of software is far bigger than the upfront development cost.
Mentioned in Dispatches 
Wrong… this is where there are a lot of misconceptions.
Use Cases are not the same as user stories. In this small snippet you quoted (I’m assuming context since I’ve seen Cohn’s work in the past), it is implied that Use Cases were created as documentation and the user story appeared and disappeared within the sprint. The use cases must be maintained across time for the life of the product.
Scrum and XP don’t talk about documentation and maintenance much, but also does not exclude it (XP suggests that automated acceptance tests can replace some documentation). Crystal and Lean (and Kanban) talk about this stuff more. Agile is an umbrella over all of this. Nobody succeeding with Agile will say that it throws out the documentation or can’t be applied to maintenance projects.