On modern machines, C doesn't even expose some of the more important issues related to hardware. I am referring to things like the memory consistency model, cache coherence, different abstractions for multiprogramming and how they are implemented in hardware - GPUs vs. shared memory MIMD vs. MPI vs. clusters running MapReduce and so on. I'm not saying these programming models can't be implemented in C. I'm pointing out that learning C won't automatically teach you about the tradeoffs between message passing and shared memory systems. You still have to go out and learn that stuff. I'd argue that in today's world this is about as important as learning what malloc and free are doing under the hood.
Fred Brook's notion of classifying the complexity of programmable systems into essential and accidental complexity is useful here [1]. No matter what language you start with, you'll need to learn to deal with the essential complexity of software systems. In that regard C# is as good as language as any other. In fact, it might even be better than C because you get to focus a little more on the essential complexity because it is a higher-level language than C.
I think the advice of learning C first came in an era when hardware abstractions were simpler and so simply learning C would go a long way towards helping you understand how your computer really worked and thus in one sense helping you cope with the accidental complexity of software. But I think that advice might need to re-thought now because both the hardware and the software systems we build and use today are so much more complex. Just learning C alone might not get you very far in terms of understanding what really happens on your machine when, say, your webbrowser is making a HTTPS request to google.com.
[1] http://faculty.salisbury.edu/~xswang/Research/Papers/SERelat...