I think the problem is largely that "10x programmer" is ambiguous between "10x more valuable" and "consistently produces code 10x faster". I think people accept the idea because of the first meaning, but efforts to hire 10x engineers frequently look for the second.

There are certainly lots of programmers who produce 10x more value than others, and some who produce 10x more than average. They create good project plans that don't need reworking midstream, build tooling pipelines that save work for their whole team, catch obscure-but-expensive bugs in advance, and make sound design/infrastructure choices which save huge amounts of renovation down the line. And yeah, for sufficiently-hard problems they sometimes come up with clever technical solutions other people wouldn't.

I suspect there are engineers who can frequently output quality code 10x faster than most of us would, but that's reserved for incredibly specific tasks. Most code-writing genuinely can't (or shouldn't) be accelerated like that, so it's limited to arcane problems like rendering or codec work where brilliant optimization can trump general diligence. John Carmack might be an example, or Dennis Richie, or Gary Tarolli (who apparently first authored Fast InvSqrt). The Microsoft gurus who hand-edited the EQNEDT32 binary for a bug-fix, too. But there are maybe a few thousand programmers in the world doing that sort of work, in a very specific set of fields.

Meanwhile there are a lot of companies trying to hire "10x engineers", often for "make our website and backend" tasks that can't possibly be solved with a brilliant coding trick. And a lot of those companies aren't looking for someone who will do the architecture and task-analysis and tool-building that makes 10x-value engineering possible, they're looking for someone who will solve simple problems inhumanly fast. In practice, that mostly means cutting corners, hard-coding values, and skipping on documentation.