An excellent point and one of the many reasons I prefer C for most things. It's easy to understand the rules and what will actually happen.
Er, no. Or at least only at a superficial level.
As merely one set of examples of how developers have been demonstrated to be confused, have a look at https://queue.acm.org/detail.cfm?id=3212479 and its references.
Of course, for numerical work FORTRAN is better. Lex, yacc, awk and MATLAB/Octave all have their places too.
Er, yes
Sadly, I would not disagree about the knowledge level of the generic programmer. My general observation is that the entire compile, link, execute cycle is magic to most for any language, even K&R C or C89.
I'm not the generic programmer. I have copies of the language standards and refer to them whenever needed. I *never* call a library function without checking the argument types and orders unless it's a function I just used a few minutes earlier. I also have and have read several books on compiler optimization and "Computer Architecture: A Quantitative Approach" by Patterson and Hennessy. I've only read the first 3 eds. of the latter as I've not had a serious project since the 4th ed came out. But it would be the first thing on my To Do list if I were tasked with a high performance programming assignment.
Programmers have even less of a clue what C++ does. In fact, I assert that no one understands C++. However, I shall not bother with my canonical example. Suffice it to say that I can present a trivial code example which will require reading all the source code, the language standard *and* the compiler implementation notes to figure out what one line does.
I read language and processor manuals for entertainment for many years. I am what Fred Brooks described as a "language lawyer".
For example, section 8.3.5 of the F77 standard says "upon return from a function or subroutine, named COMMON may be undefined". This language was inserted into the standard at the behest of Burroughs so that they could state that the new Burroughs 5000 had an F77 compliant compiler. That machine was one of the first stack based machines and so far as I know the only machine that implemented a tagged architecture. Every memory location had bits that stored the type of value stored at that address.
When the first RISC machines came out, I spent a lot of time explaining to people what they needed to do to make their code work. I've also done little stunts such as demonstrate passing data between functions without using globals or arguments by exploiting the order in which automatic variables appeared in the stack frame.
Curiously, I've never seriously used F95 and later. Copies of the standard are expensive and I've never found a decent book on modern FORTRAN that explained what the underlying memory map and structure was. Of course, that is in part because I can seamlessly move between C89/99 and F77. I got a 6x speedup in a program by having C create a table of F77 function pointers and addresses on the first call and then executing the table after the first call. This was a big deal with users who were processing 100 million line ASCII files.