One instance is a colleague who needed to do data post-processing, and just did it in C because it was most familiar. A language like Perl or Python would have been a better choice, and saved him time in the long run, since string manipulation in C is tedious and error prone.
But I agree, C isn't the best choice for that task.
People often write in higher level languages because they want lots of bad code fast.
Your second assertion is spot on. If one needs to develop a high performing solution optimized for speed and memory consumption, plus high reliability and if it also needs to be reasonably cross platform, one would gravitate towards C. Add to this the established heritage/ecosystem and the tools, and availability of a (relatively) big pool of programmers, C tends to be a good choice.
The only con is a relatively longer development cycle. (True only for mortals like me though, some people stream out C code faster than i write an email. :-) )
This gives you the advantages of a high level language where the extra overhead and consequences for coding a little poorly aren't as detrimental.
In the 90s it was Visual Basic, now it's Java and C#, but it has absolutely nothing to do with what most of us consider to be discussion worthy.
It just runs our banks, hospitals, governments... Much better to solely focus on those that write kernels, device drivers and filesystems?
That's the kind of programmers this industry attracts, and that's the kind of software it builds. What's so interesting about it? Why even bother mentioning these numerous java/C# jobs? My ex-wife with zero programming experience has trained herself in less than a month to run a simple SQL queries in Visual basic and blast results in a grid control on a form, so did thousands of ex-taxi drivers in late 90s. So?
To be honest, I'm still not sure what point you're trying to make is. At best it's somewhat of an Ad Hominem attack.
"People often write in higher level languages because they want lots of bad code fast."
Even if this is true, it's true only in enterprise software environment where code quality has never been terribly important. Therefore it can't really be an argument against higher level languages in the context of a typical HN discussion.
Makes sense?
I'm in no way trolling here, but if you think about it, most of the guys working on startups are also producing lots of bad code fast. The only difference is that most of them are aware of it, and will improve the code based on the requirements from the market.
If you are heavily into programming, as it seems you are, I can understand that SQL queries seem trivial and boring. If your interest is elsewhere programming is often just a tool used to create the interesting stuff. Whether that is usability, design, getting people to interact in new ways, launching rockets or automatically turning off your garden lights when your computer powers down.
Believe it or not there are interesting discussions to be had about other things than programming.
Of course I'm generalizing, and a lot of C# programmers write great and reliable code. The point is that they often don't -need- to write great code, because lousy code is good enough for all business purposes (except when the software is your product, which is rarely the case).
The second issue is that people who choose C for their projects tend to (a) understand low-level concepts, (b) care about speed / memory usage / reliability / dependencies, (c) don't consider development time that important. That you create more reliable software that way is obvious - the same programmers would create reliable software in C# (or similar language). But there aren't many situations in which development speed doesn't matter, speed and memory usage don't matter, dependencies don't matter but, for some reason, reliability is very important.