I TA'd an introductory computer architecture course (basically, start with a MOSFET transistor and end up with "here's how you write malloc/free"), which was students' first introduction to both assembly and C. That experience helps solidify that you really want to students' first experience with programming to be a high-level language.
One of the problems with teaching is a phase-ordering problem: what order do you teach the concepts in? As GP notes, C starts you off with a lot of boilerplate that isn't going to become relevant until a month or two down the line. Concepts like functions, libraries, the insanity that is the C preprocessor are distractions when your first challenge is just getting people to understand the mental model of how a procedural program works (i.e., understanding what x = 5 really means!). On top of that, C imposes a mental burden of understanding the stack versus the heap and the relevant memory management concerns. And then you get into C's string handling...
I suspect many of the people commenting here are in the class of people for whom programming was obvious and easy, and never struggled with any of the concepts. This class of people will do fine with any language being used to introduce the concepts, because they're not really learning the concepts. Where the language matters most is for those for whom programming is not obvious, and they need help identifying which parts of the material is more fundamental than others. Giving these people a language that is more forgiving of mistakes is going to go a longer way to democratizing CS education than insisting people start by learning how computers really work.
That isn't to say that this isn't something that should be taught pretty early on: far from it, I think a computer architecture class should be the second or third class you take on the topic. Delaying the introduction of C until computer architecture means that you can use C as a vehicle to introduce all the other parts about computers that are important, such as 2's complement arithmetic, ASCII, what the stack and heap are, etc.
One of the problems with teaching is a phase-ordering problem: what order do you teach the concepts in? As GP notes, C starts you off with a lot of boilerplate that isn't going to become relevant until a month or two down the line. Concepts like functions, libraries, the insanity that is the C preprocessor are distractions when your first challenge is just getting people to understand the mental model of how a procedural program works (i.e., understanding what x = 5 really means!). On top of that, C imposes a mental burden of understanding the stack versus the heap and the relevant memory management concerns. And then you get into C's string handling...
I suspect many of the people commenting here are in the class of people for whom programming was obvious and easy, and never struggled with any of the concepts. This class of people will do fine with any language being used to introduce the concepts, because they're not really learning the concepts. Where the language matters most is for those for whom programming is not obvious, and they need help identifying which parts of the material is more fundamental than others. Giving these people a language that is more forgiving of mistakes is going to go a longer way to democratizing CS education than insisting people start by learning how computers really work.
That isn't to say that this isn't something that should be taught pretty early on: far from it, I think a computer architecture class should be the second or third class you take on the topic. Delaying the introduction of C until computer architecture means that you can use C as a vehicle to introduce all the other parts about computers that are important, such as 2's complement arithmetic, ASCII, what the stack and heap are, etc.