Agreed, The example the author uses in his previous post on the topic talks about cache-unaware code but it's perfectly possible to write cache-unaware code in machine language as well.
I'd say "C is not how the computer works ... but it's much, much closer than nearly every other language."
I feel your statement is actually much closer to the danger. C is pretty close to the hardware indeed and that misleads people into thinking that C is actually exactly how the hardware works. It's a very easy trap to fall into and I've seen many colleagues do just that.
I don't see why it would. Given what modern CPUs do to make memory fast and safe, pointer arithmetic is a ridiculous simplification that has no bearing in reality.
That is no argument in this discussion, IMHO - what does it change? The discussion is about the language (and in case of Java, the runtime) and it's machine abstraction, which is nearly the same for Java and C, even if JVM was written in Lisp.
My point was that many people who just now come into C fall into the trap of thinking that it [almost] exactly mimics hardware. Which is an easy mistake to make if you are new to the thing because it's taught as if it's a panacea and sadly many people believe those university courses.
As for former colleagues, oh well, we all learn and grow. I chose to bail out because something as non-deterministic as a C's code stability when cross-compiled for anything more than two systems turned me off. Different strokes, different people.
I'd say "C is not how the computer works ... but it's much, much closer than nearly every other language."