Speaking from experience, this myth was never true from 8086 up through the 486; the Pentium (P5) might've been slightly harder to optimise for, but a human could still easily beat the compilers of the time. And of course, it is not true today either.
Around the time of the P6 (Pentium Pro/II/III) was when I think things really improved - out-of-order execution/speculation/wide decoders meant instruction ordering had little significance, and so getting more performance was more about reducing the number of instructions needed - something compilers tended to not do well at.
I believe the myth came from the early days of the RISC fad, where CPUs were designed specifically so that compilers could easily generate code for them and make human-coded Asm "obsolete"; although to me this appears to be more of a "take all the advantage away from humans, making it just as hard for them to optimise the code as the compiler"... I have only a little experience with writing Asm for MIPS and ARM, but even from that I can see they do not have anywhere near the sort of "room for optimisation" that x86 provides.
Another myth that probably needs to die now is "microcoded instructions are slow"; in a recent article on HN about using the old BCD instructions which were commonly thought to be much slower than an equivalent sequence of simpler instructions (https://news.ycombinator.com/item?id=8477254 ), I did a quick benchmark and found they were basically the same speed, but much shorter. The one caveat is that currently these complex instructions can only be decoded by one of the decoders, so having too many of them close together can slow things down if the other decoders can't find a simpler non-dependent instruction to decode; but using them sparingly could be good for making code smaller (and thus consume less cache) without any speed penalty, or possibly increase speed overall due to reduced cache misses.