I'd accept "how it would compile to assembly" as "understanding the machine-level behavior of the code," but again, I find this extremely lacking with Java. I

I'd accept "how it would compile to assembly" as "understanding the machine-level behavior of the code," but again, I find this extremely lacking with Java. I don't know what percentage of developers can read assembly, but the popularity of tools like Godbolt strongly suggest it's non-zero. In my own experience, all of the most skilled developers I've worked with have been comfortable digging down to the necessary level -- and doing that in Java, or most other JIT'd languages, is just not fun. You'll notice that I very much didn't put C++ on either the "easy to understand intent" or "easy to understand behavior" lists -- while it's my preferred language and my primary language, ease of understanding is not its virtue. And while I agree that C compiled with a minimally optimizing compiler (CompCert, clang -O1, etc) is easier to understand than optimized code (for me, the sweet spot for understanding is as compiler that does good register allocation and constant folding, but only really does instruction reordering for memory ops), it's pretty rare that I look at the output of highly optimized code and am surprised or find it hard to follow. Some constructs (medium sized switches, for example) can be pain points... but most often reading assembly output from optimized C is either "yeah, that's about what I would have written" or "close, but you missed this optimization/intrinsic, I'll do it myself."