The truth is, J2EE 1.0 was not designed by grown ups. It was designed by college kids and academics who ironically enough wouldn't know the 8 fallacies of network computing if it but them on the ass.
Because it DID bite them on the ass and we have nearly 5 years of vendors flaunting and then polluting the spec to prove it.
Then we have Josh Bloch, who everyone but me thinks is great, who introduced Duck Typing to the JDK (MethodNotImplementedException) and only later confessed that he couldn't understand variance. People defend their bad code by pointing to similar code in the JDK, and Bloch stunted the growth of an entire generation of developers. Then repeated the exact same mistakes at Google.
Me, I'm waiting for a language that Bloch had nothing to do with, and I want to get back to working in limited resource environments. My eye is on Rust right now, and I have my fingers crossed.
This isn't a great comparison because C was, and still is, a much lower-level language than COBOL. If you're looking at that from the perspective of a large organization with millions of lines of code, it's hard to justify the claim that C is “technically more suitable”, because the things C does better are largely irrelevant to business apps while the ISO standard for COBOL includes a ton of higher-level features like an indexed database, first-class support for fixed-precision math (a hard requirement for financial apps), a form library, object orientation, etc. which would need to be maintained as library dependencies in C. Any COBOL programmer would be familiar those but each C developer would need to get used to each application's particular selection of libraries.
A better comparison would something like Java or .Net which both have standard answers for most of those questions and, perhaps unsurprisingly, were quickly adopted by companies trying to move new development away from COBOL. As far back as the mid-90s, a popular approach was to move the front-end into Java (or, later, a web app) and start chipping away at the decades of backend COBOL code running on a big central server.
Can OpenJDK create a fork of the whole Java ecosystem when Oracle wrecks it?
Love 'em or hate 'em, Oracle didn't turn into a factory farm of cash cows by being entirely incompetent.
Yet, java was (as someone recently disparagingly put it) "designed by adults". By people familiar with state of the art language research, what was needed and workable, comprehensive specs of language and VM, and complete stdlibs, docs and tools from the get-go. (That is, disparaging to other languages)
And it's also managed to keep up to date, much better than I'd ever have thought: fast JVMs, language evolution, stdlib extended - and perhaps the greatest number of 3rd party libraries of any language ever(?).
Oracle is wrecking that for EE, and may wreck more.