In that regard, a case can be made that when you're writing in C, you're writing exactly as close to the bare metal as if you're writing in, say, Go or Haskell.
No, you really can't. This is childish black and white thinking. The computational model of C is built on an interface exposed by the hardware. Go and Haskell build many additional abstractions on top of that same model.
This article could have had a fruitful discussion about what the author is trying to say, but by choosing such a clickbait title, he managed to turn it into a discussion on semantics that wants to deny useful distinctions, because in some context (not the context in which it's actually used), it doesn't fit.
This kind of linguistic wankery really pisses me off, because it's useless and rests on a misunderstanding of how people actually use language (which is to say, in context and often in relative terms).
Haskell, Go, et. al. are understood to have complex runtime machinery atop the x86 instruction set. It's an erroneous belief that C does not (and one that I've seen developers get bitten by repeatedly as they try to manage threaded C code).
I think it just leads to quibbling over the boundary of low level, as is happening here.
I think it's just important to know that the definition changes over time relative to the state of the art. C was once considered high level. In the future, if programming languages evolve to a more natural language state, then sending serial instructions to the computer in a strange code will seem very low level to such programmers.
Anecdotally I have encountered loads of programmers who actually believe that there is a straightforward correspondence between C code and what the machine is actually doing, which is wrong.
So regardless of how you want to define "low-level", understanding this point is useful.
That really depends on your definition of "the machine". If "the machine" is "hardware", then sure. But if software is a considered piece of logic onto itself, that, when pitted against a sound model of an architecture will result in a series of logical steps, it's different: there is a very straightforward correspondence between the model-machine and assembly/C. Whether there is a 1-1 correspondence between the model-machine and any accidental hardware it is implemented is not that relevant.
So if low-level is defined as the lowest level that any hardware abstraction functions exactly as its logical function and not its silicon, it tells you exactly what the machine should be doing, even if it's doing it through different means.
I believe one of the points the article is making is that, no, there is not. Pin down a C developer's actual understanding of how C is converted into x86 or x86-64 assembly, and you find that nobody actually has that abstraction riding around in their heads, because the abstraction they do have riding around in their heads would make for some unacceptably non-performant code. Even if we disregard the fact that x86 is emulated on modern hardware, the C -> (Clang + LLVM / gcc) -> assembly path is deeply complicated.