It's a natural fit for enterprise programming where time to implement is usually key and logic is endlessly extended to accommodate whatever new business requirements emerge after the last round was deployed. And robustness is valued more highly than raw performance. Use Java - pay for twice the servers and get ten times the uptime? Done.
That means that days or weeks spent hunting your latest memory corruption issue makes C a non-option for these applications.
As for mediocre programmers - sure, and a large bunch of mediocre programmers scales, whereas a small team of star programmers doesn't. Someone has to tweak the UI. Someone has to implement all that tedious persistence logic. You need star programmers for that? No.
I'm excited to see if Go intrudes on this field, but it's a big field and Go's just starting out.
In the kind of situation GP describes, what matters is probably the well-established practices for extending the behavior of an already-built system without breaking what's already there. A lot of Java practice has built up around having behavior determined dynamically (OOP is a nice fit for that, whereas C does not have great facilities for it). Much of the "ceremony" involved in using the big, complex Java frameworks is about preparing a piece of code for eventual extension. When some behavior is hard-coded in, it's difficult to change later, so the code is parameterized over anything and everything that might eventually change. Of course this looks silly when you do it for small things that won't change -- no need for FizzStrategy and BuzzStrategy interfaces when the only thing you'd ever want to do is print "fizz" or "buzz".
Quite a bit of that programming practice did develop in C++, but Java as a language provides stronger safety guarantees than C++ (lots of memory-related errors are difficult to impossible to have in Java) without sacrificing all that much performance. When you ask for a reasonably performant, statically-typed, memory-safe, object-oriented language, you're going to get pointed at Java (and C#). So that's what people use in that domain.
That means that days or weeks spent hunting your latest memory corruption issue makes C a non-option for these applications.
As for mediocre programmers - sure, and a large bunch of mediocre programmers scales, whereas a small team of star programmers doesn't. Someone has to tweak the UI. Someone has to implement all that tedious persistence logic. You need star programmers for that? No.
I'm excited to see if Go intrudes on this field, but it's a big field and Go's just starting out.