This is really a matter of scale and reality. Let's think in survival terms. Some applications, oh, say High Frequency Trading depend on getting the calculation done first. We are talking milliseconds or less to do a calculation that leads to placing, cancelling, or modifying an order. Do they use assembler? No. Problems of scale requiring massive hardware or clusters, do they use assembler? Not generally. Often they use Lisp, C++ or C.
So in the context of real-world problems, compilers win, because none of us has the energy or attention span to write it in assembler, something the size of a real-world problem like, for example, a compiler.
We optimize small problems by hand, but problems of useful size we don't because the compiler does a better job on problems of true interest than we have the patience or time to do.
To put it another way, it is better to put energy into improving compilers than getting into a John Henry type of competition.
Your point is well made, but if the large, relevant problem can be broken into small sub-problems, and if one of those consumes a significant amount of compute time, then that might (just might!) be worth optimising in assembler.
My experience of problems requiring massive hardware or clusters (limited, I admit, to certain classes of scientific computing) is that such assembler coding of speed-critical components is actually often done.
So in the context of real-world problems, compilers win, because none of us has the energy or attention span to write it in assembler, something the size of a real-world problem like, for example, a compiler.
We optimize small problems by hand, but problems of useful size we don't because the compiler does a better job on problems of true interest than we have the patience or time to do.
To put it another way, it is better to put energy into improving compilers than getting into a John Henry type of competition.