I am puzzled by the claim that C and assembly are not relatively close.

Note here “close” being used in the injective, not bijective, sense. (Scratch out “one-to-one” in my earlier comment.)

And “closer” lowers the bar here too. C isn’t simply decorated assembly. But closer to it.

And “close” being used informally. Arguments for closeness are several and strong (I think), but a bit of a hodgepodge.

In terms of non-bijectivity, for systems programming and performance choices C makes it easy to drop into assembly. But the former are uniquely application specific. And the latter doesn’t make the C version less like the assembly it maps onto - whether the compiler uses the more performant instructions for the context or not.

C’s convenient assembly inlining, and the handoff in both directions being smoothed by an assembly friendly model of the C code around it, are both a part of the “closeness”

But C is generally “close” to assembly, because its data types emphasize types handled natively, compound types reflect RAM layout, and pointers are explicit addresses to data and code. And those address values can be constructed and operated on just like any other data.

C is objectively closer to assembly than languages with strongly required abstractions. (E.g., Java classes, Lisp S-exp's/cons cells, etc.)

C is more “strictly closer” to assembly than languages with more optional abstractions, even if they also allow for relatively low level coding.

Functions could be viewed as a preferred abstraction, but they have a clear assembly level model accessible directly with pointer arithmetic. And they don’t get in the way of directly encoding custom argument passing schemes, and using goto’s and zero argument functions and tail calls as atomic assembly calls for function and jumps for continuations.

Types are a significant non-assembly abstraction, but are zero-cost in that they don't separate C from assembly, but C from C, as a code safety mechanism that is easily escaped.

It is often easy to add abstractions, via regular C, or macros, but you have to provide an explicit implementation for them in the source or complied library.

(However, if macros, with their mixed logical, symbol, text and file “data” model, are viewed as C source instead of as a C source construction language, then C becomes a very wacky abstraction language with behavior and rules that look nothing like simple assembly.)