C having better support for pointers makes it nearer to how the processor works, compared to other languages.
Java is almost entirely pointers to heap allocations, yet I don't think anyone would argue that Java is close to how the processor works.
I also don't think that the C virtual machine is all that close to how machines actually work any more.
C semantics do not work "directly on the hardware" but instead on an abstract machine that is then converted to the actual hardware.
It most often comes up when talking about undefined behavior and pointer behavior.
Some assorted reading, mostly in the context of Rust and C:
https://blog.regehr.org/archives/213
https://raphlinus.github.io/programming/rust/2018/08/17/unde...
https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
https://www.ralfj.de/blog/2017/06/06/MIR-semantics.html
[1]: https://stackoverflow.com/questions/53100198/what-is-the-pre...
Assembly once worked directly on the hardware. On modern machines it doesn't.
Means I can at least dig through some old codebases and understand what's going on.
Lots of higher level languages also have C bindings, so at least a couple of times in my career I've ended up writing short C modules for speed critical bits of code.
The pain of manual memory management also gave me much more of an appreciation of its pitfalls and alternatives.
The Rust people are working hard to support everything that C does, so in the future C and asm will probably not have a monopoly there. But this is still not our reality.
1 - Of course, not a PC software stack, and not on any ARM available today.
If I had to pick one language to code in for the rest of my life, it would be C.