There is little value in knowing if a given line of code translates into machine instruction X or Y or into none at all. Simply write readable code and trust the compiler until you have a reason to do otherwise. In aggregate your code will be fast (not the fastest).

Once you measure a performance issue you can focus in on one part or algorithm and map abstractions onto hardware, which can't be done in many languages. Because hardware is different this process is often different. Even between two members of the x86 family there are different ways things can be optimized and the compiler puts a bunch of reasonable defaults in. Once you know the sane defaults are not good enough you can trade effort for efficiency as much as you want and keep getting gains for a long time.

Trying to go to the machine code each C++ build is like trying to understand the JVM bytecode for each java build. I don't know why so many care, because you only need to do this on occasion. I suspect the culture of performance causes people giving talks to focus on this. Then people consuming talks place disproportionate value on this.

This is clearly happening with constexpr and template metaprogramming now. Few people really need it but there is huge focus because a few smart people needed it to solve their problems, and those people are also prolific speakers and, bloggers and authors. Where are all the talks on best practices around smart pointers, thread synchronization tools, class composition, and other common issues that affect correctness, design or other aspects of creating software? I want to see more on Hazard pointers and other pooled smart pointers, these are a real replacement for general purpose garbage collection, but the community prefers to talk about compile HTML parsing (not that these are mutually exclusive, but there is only so much attention).