Anyone who says C is not important hasn't worked on embedded systems or operating systems.
I work on embedded systems. There are roughly 3 choices for languages[1]. C, Ada, and C++. Except the version of C++ is sometimes often vendor specific and may lack features that are "standard C++", and never have a "full" STL. In addition, if you're not super careful with C++, what you thought was a copy or declaration can execute additional constructor or assignment logic. It might just interfere with your estimate of how long something can take (which is super important in interrupt handlers), or worst case, smash your stack (which can be as small as 1-2k). With C, you pretty much know what's going to happen and what's getting called. The fact that C doesn't require a runtime (nor does Ada), means you can use it to write kernels. You can't do the same with a 'full' version of C++, so you're back to a cut down C++.
I also spend time debugging compiled, optimized code by tracing instructions. This is hard enough in C, where I don't magically jump to a constructor function or an assignment function. I can visualize in my head how the C code could look like, given the instructions the optimizer produced. So it may not look like my code, but it is a version of the code that I can at least logically infer.
Ada is nice, but outside of some super-safety critical realms, it hasn't had the uptake. Private industry prefers not having to make the investment and the government let everyone waive out of it.
1. I know people are going to to say 'what about Rust, Go, or embedded something or other?' They are not as mature in their development lifecycle. So there's no validated RTOS for Rust (there are some experimental ones). Go is even further behind. Basically, you need a vendor supported RTOS that's validated for the safety and operational requirements of your use case, before you can be a serious choice for a lot of embedded work.