I believe that /u/GoodLittleMine was more focusing on the trends of using C for user-level applications rather than within a kernel.

Back to the original question though, C has long since been used for applications because of the historical speed and memory efficiency benefits over Java, C# and other "higher" level languages. Modern Java and C# runtimes tend to be very fast in comparison with the C equivalents though, and in some cases even faster. Because Java is pretty quick these days, combined with the rich libraries, ease of writing code and the safety of having a managed language, quite a few applications are written in it. I believe there's still a some memory overheads, but they're not too significant.

My opinion is firmly that C should not be used for modern application code; it's simply too unsafe and requires the programmer to manage basically everything themselves, not to mention the huge source of bugs that pointers bring around when mis-managed. C++ with smart pointers and references is something of a step in the right direction, but still makes it perfectly possible to shoot yourself in the foot if you don't do things the "C++ way".

Newer managed languages help the programmer and don't let you do it that unsafe way (well, not without explicitly telling the runtime that you're doing unsafe stuff), and hence a large class of bugs caused by dealing with memory explicitly (i.e. a pointer going off the end of a block of memory and smashing a few other variables) don't happen. Moreover, the time saved when writing your application by allowing the runtime to manage the lifetime of allocated memory and other resources from the operating system far outweighs any performance detriment for most applications.

Of course, this isn't to say that C is fully dead and you should never use it ever. It's still used in operating system and firmware code because it's close to the hardware, can just access arbritary memory, and can run with basically no runtime library (all it needs is a small loader to set the stack pointer and clear the .bss section). It's also used on small embedded systems with minimal operating systems (i.e. FreeRTOS or embedded Linux) because there isn't enough memory to fit in the full runtime required by a managed language), or for low-level system utilities (think coreutils etc) where it can't be guaranteed that the runtime for a managed language will be available. C++ can sometimes be used in these use-cases though, as long as you're careful about what you use (and don't accidentally pull in a huge bunch of library code).

It's also used sometimes on high performance applications which need every bit of performance they can get, or can't deal with the non-determinism caused by the runtimes (i.e. Java doesn't run the JIT at deterministic times), for example, game engines. These are really special cases though, and I'd be interested in seeing if it's viable to write a game engine in a managed language.

C's not dead, it's just that you really shouldn't use it for application-level code any more.