It’s not irrelevant if Intel has tools to let you close that gap easily.

Unless you're doing low-level stuff no developer is going to be aware that this even exists, much less capable enough to use it. There are more 'programmers' than 'engineers'...

An extreme example of the tooling gap: MKL. Intel made MKL and used CPUID and instruction set optimizations in a non-conformant way that penalizes AMD; it's a fair bit faster than OpenBLAS on (to-date) dominant Intel hardware.

If you make CPUID lie to it that it's an Intel part, it'll use AVX2, and Threadripper parts will beat Xeon by a 20% margin. Otherwise it's 200%+ slower.

Meanwhile, MKL has been a fair bit faster than OpenBLAS, etc on Xeon ("pretend to be Intel" MKL and OpenBLAS are about the same speed on AMD), so all kinds of software is linked against Intel MKL.

When you have core libraries tuned for Intel, either because Intel makes them themselves or because the tooling for performance tuning on AMD hasn't been present, Intel has a software tuning advantage that helps hide AMD's current silicon performance advantage.

Tools can't close a gap of entire cores, much less twice or more of them.

It's a matter of principle.

Some people don't want cores that you can't gather insight into how you are spending/wasting their time.

I'm not a direct customer of Intel or AMD, but in general I would trade off clock speed/cores/cost for insight into what my software is doing.

Extreme example: MKL on AMD is 3x slower than on Intel. Meanwhile, if you lie to it and say you're an Intel part, MKL is 20% faster than Intel...