I say this as a person who loves C and taught it lovingly to undergrads for many years.
Embedded system programming is a lovely niche, but we don't need to design CS curricula around it.
This seems like not teaching calculus because you can do it on a calculator. I didn't do a degree that focused on C development, but I still had to know how to do it. God forbid any of your graduates end up working on an operating system at some point.
I didn't propose that.
I'd expect a good curriculum to expose students to several languages, so that picking up another one is not an ordeal.
Take, for example, the entire stack-and-heap thing. That's not a bedrock feature of computing; it's merely a thing that was particularly convenient to do on a PDP-11. But if you're working in C, you have to do it - so it stays a "seemingly bedrock" feature even if the hardware has drifted far from the PDP-11. A lot of these features boiled down to the ISA making it fairly convenient to do them that way - there were built-in instructions that made it pretty easy to "color-by-numbers" and get the job done.
---
This is similar to how we (societally) did barely any woodworking with screws before we had the industrial processes (like lathes or whatnot) to make them. Nails weren't some magic ground-truth or axiom of woodcrafting - it was just obscenely difficult to craft a screw, so why would anyone in their right mind attempt to build something with them?
For my master's I took a course on static analysis, for which we had to perform usage analysis, type error diagnosis, implement a type checker etc. All in... Haskell.
If a CS/Engineering program doesn't have an OS class with non-trivial labs in C, it's simply not serious and a red flag on a resume.
Furthermore, 6.004[1] looks like it has to involve C at some point.
[0] http://catalog.mit.edu/degree-charts/computer-science-engine...