The Scrum Issue Type Scheme comes with Epic, Story, Bug, and Improvement as first level "issues". Technical tasks can be created as children of stories, but not as first level cards.
I was thinking of using "improvement" cards to represent work like refactoring, or non-user exposed technical tasks that don't relate to a specific user story. (This would elimiinate my need to go through the IT department to reconfigure my project to include a new "Task" card type).
Before I do that, though, I'd like to understand what the "improvement" concept was initially intended for in an agile context. It appears to me that it is simply a carryover from the default scheme from my research so far.
I think you're research is accurate that this is a carryover from the default scheme, but the use case you've described fits perfectly with the original intent of the issue type in both Agile and non-Agile contexts.
I don't recall exactly when, but I'm pretty sure the 'Improvement' issue type was there before the Agile plugin (the artist formerly known as GreenHopper) became available for JIRA.
Your use case makes sense though. The main thing is to just make sure everyone in your organization understands how and when the issue type should be used.
Say you had a whole lot of the type of "improvement" work that Adrian was talking about for a sprint. Since JIRA doesn't allow you to assign any estimate to improvement issues, wouldn't that defeat the purpose of accurate estimation. Say that the improvements account for 40% of the work. Using JIRA the estimate would be the same whether you plan to do these improvements or plan to sun bathe every afternoon instead.