Why Cobol Wont Die

Possible reasons why COBOL is still around in such numbers:

It is not subject to round of excessive enhancements or upgrade cycles. The "hype tinkerers" have happily abandoned it. Stability has value. It's somewhat comparable to latin's use for medical terms because a dead language won't go changing on you.
The use of RDBMS has made the division-by-task nature of COBOL not as problematic. Instead of "one big EXE", problems are split into multiple smaller tasks or events that communicate most via the database. Thus, its "global variables" are really only module-level variables. (See ProceduralMethodologies).
Business logic is mostly just a bunch of conditions (IF statements) such that higher abstractions cannot offer significant improvements in many cases. Applying abstractions to business rules often leads one to get snagged in the EightyTwentyRule trap where an abstraction that does 80% is not sufficient because of the 20% it cannot handle.
Its decimal libraries are often more accurate for currency calculations than floating point, which are optimized for speed and compactness instead of mirroring currency math rules. Many newer languages decided to use only floating point, to simplify the languages.
It has powerful commands, in the language, for things that are commonly needed for business processing -- like SORT.

An alternative explanation: inertia. The existing code works, and no one wants to change it right away. Most all cobol code being written now is maintenance of old cobol code. No one, and I mean no one, starts from using cobol now. It is dead, it just yet hasn't decayed completely like PL/1. One could argue it's better-preserved, but no one is saying it is still breathing.

RE: "not subject to round of excessive enhancements or upgrade cycles"

On the other hand, standard COBOL does get upgraded: 1968, 1974, 1985, 1995, 2002, 2008 (planned).

Other than decision and loop blocks, most of the modifications have had limited acceptance/use in my observation.

Without user defined types, I found COBOL-85's nested programs quite useless: You can't pass a "CUSTOMER" around to different subprograms without duplicating the definition many times -- or playing nasty tricks with COPY members. (I'm a C++ hacker. I'm more than willing to play nasty tricks with COPY members. But I do have some minimal concern for future COBOL-native maintainers, so I refrain. ;-)

ImpedanceMismatch??

I think from the BigIron perspective, CobolLanguage will continue. OTOH I have not seen much mention of this language on distributed Application servers, etc. There were implementations like MicroFocusCobol but these were not seen much in the 21st century.

Personally I think where appropriate, CobolLanguage is the most maintainable language, because even spaghetti code written by programmers long departed can be tracked down, much easier than the "modern-day darlings" (PerlLanguage is probably one of the extreme on the other end).

In late 05, MicroFocusCobol was reported to have won US Army contract to migrate away from BigIron implementation. See http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20051108005027&newsLang=en

About the California payroll debacle.

http://weblog.infoworld.com/fatalexception/archives/2008/08/californias_leg.html

See CobolLanguage, CobolIsDead