I think everybody here is confusing syntax, power and tool scope.
Every successful language has a syntax tuned for it’s task (sql has a good syntax for data manipulation, c for memory/register manipulation, awk for lines of text manipulation, etc).
COBOL is not an exception. Yes, you can see that fragment of code and think what a verbose thing. You are wrong! COBOL syntax if pretty compact for what it is designed to do. You are just looking at the wrong example. Try writing a Java (or other modern language) program that receives an input file (say XML, reads every entry, does some calculation and writes it back to the same format and you would get exactly the same verbose bunch of lines. On the other hand, write an online processing server and the same language is very succinct.
COBOL was successful in it’s days because it’s very close to assembler (the syntax is easier to maintain but it can be easily translated). It has no dynamic memory allocation (so you can guarantee performance for every transaction, which is not as easy in modern languages).
And it’s oriented towards data processing, NOT object or functional processing.
This should not be a problem for anyone trying to use the right tool for the right problem (unless of course you plan to use awk to write your next mission critical accounting application).
I think it’s unlikely that it will go away as it is still very efficient doing what it does (that’s why it’s wrapped with new technology’s applications).
If nature and evolution enhance what is already there to create better organisms, i don’t see why our industry should work different.
In this scenario you would be tempted to make a secuence of calls, but the problem is that you can jump from inside one of these blocks to another. This, i believe, was the right semantics when COBOL was created, because memory and disk was scarce, but most important, because at the time, modern CPUs didn’t have stacks and call/return instructions (if you can imagine such a world :-).