What the heck, I'll chime in with my $0.02.
In many instances there is a real or perceived difference between "systems" languages and higher level languages. I'll ignore most "higher level" languages, since nobody (at least not many) will argue that for many tasks, languages like Python, Ruby, etc. are simpler to work in.
C was designed to be a systems language, meaning it was designed as the language in which the Unix operating system was written in. As such, it was designed to be simple, powerful, and fast. A simple language gains power by means that non-systems-programmers often consider dangerous: pointers, manual memory management, etc. As has already been mentioned, C is quite simple. K&R is the smallest book on my programming shelf by far (not counting O'Reilly Pocket References) and it's only marginally "bigger" than my Ruby Pocket Reference. C is quite powerful. If you need to talk to hardware, manually check and twiddle with memory, etc. C has the capability.
From a programmer's perspective, however, C is not so simple. Speed and power come at the price of manual memory management and not much OOP support built in to the language. C++ (not my favorite language) is much simpler from a programmer's perspective, but much less simple from a compiler's perspective. Objective-C (possibly my favorite language) has the same tradeoff, with slight lean in the direction of keeping the language simple (garbage collection is a newcomer to Objective-C, for example). But since the computing world as many of us know it was written in C, it's difficult for newer, more-complicated but "easier" languages to gain widespread adoption.
In some cases, especially when the current "standard" is as "good enough" as C is, there's simply not a lot of incentive for something "better" (C++, Objective-C, D etc.) to gain traction, when there is even enough incentive to create something "better".