I see a huge semantic gap between assembly language and C.

An assembly language program specifies a sequence of CPU instructions. The mapping between lines of code and generated instructions is one-to-one, or nearly so.

A C program specifies run-time behavior, without regard to what CPU instructions might be used to achieve that.

C is at a lower level than a lot of other languages, but it's not an assembly language.

Look at the compiler assembly output after optimization kicks in. The resulting assembly code is usually significantly different from the input source code. With modern optimizer passes, C is much closer to any other high level programming language than to handwritten assembly code.

This was only the case when the machine code generated from C compilers was almost 1:1 to PDP-11, or similar 16 bit home computers.

Since optmizing compilers became a thing in the C world, and the WG14 never considered modern CPU architectures on what hardware features C should expose, this idea lost meaning.

However many people hold on to old beliefs that C is still the same kind of C that they learnt with the first edition of K&R C book.

This ACM article might be interesting to you, https://queue.acm.org/detail.cfm?id=3212479

Before dismissing it as the author having no idea what he is talking about, David Chisnall used to be a GCC contributor, one of the main GNUStep contributors back in the original days, and one of the key researchers behind the CHERI project.

C is a programming language. It makes for a very shitty high level assembler.

Here's a trivial example clang will often implement differently on different systems, producing two different results. Clang x64 will generally mul+add, while clang arm64 is aggressive about fma.

    x = 3.0f*x+1.0f;