To invest in new hardware, just to have it crippled by Intel MKL afterwards.
This was object of a question I asked here previously.
In matter modeling, it's usual for people to compile software themselves, instead of relying in precompiled binaries, so it can be tuned to the particular processor model in their machine, for example, taking advantage of more recent instruction set vector extensions like AVX or XOP to speed up calculations. By contrast, to ensure it can be run in just about every machine found in the wild, precompiled binaries rely on ancient SSE extensions, for example, thus not taking advantage of the full potential of new CPU models.
The Intel compilers are quite popular in the field of matter modeling, and numeric computing in general. Said that, it comes with the downside of sabotaging the performance of machines equiped with hardware of competitors, by unreasonably refusing to use the new extensions, as explained in this wikipedia entry:
MKL and other programs generated by the Intel C++ Compiler and the
Intel DPC++ Compiler improve performance with a technique called
function multi-versioning: a function is compiled or written for many
of the x86 instruction set extensions, and at run-time a "master
function" uses the CPUID instruction to select a version most
appropriate for the current CPU. However, as long as the master
function detects a non-Intel CPU, it almost always chooses the most
basic (and slowest) function to use, regardless of what instruction
sets the CPU claims to support. This has netted the system a nickname
of "cripple AMD" routine since 2009. As of 2020, Intel's MKL, which
remains the numeric library installed by default along with many
pre-compiled mathematical applications on Windows (such as NumPy,
SymPy). Although relying on the MKL, MATLAB implemented a workaround
starting with Release 2020a which ensures full support for AVX2 by the
MKL also for non Intel (AMD) CPUs
In older versions, setting the undocumented environment variable
MKL_DEBUG_CPU_TYPE=5 could be used to override the vendor string
dependent codepath choice and activate supported instructions up to
AVX2 on AMD processor based systems resulting in equal or even better
performance when compared to Intel CPUs. Since at least Update 1 2020,
the environment variable does not work anymore.
I think the effects of this sabotage problem tends to get worse, because, as pointed by @GregorMichalicek comment to @uLoop answer, many people in the high performance and scientific computing community are switching to AMD, given the strides they made with the Zen architecture, while Intel faces issues with their manufacturing process. But perhaps not everybody is aware of this problem, to be able to switch their compiler and linear algebra libraries accordingly, toward alternatives not biased against any hardware, specially in small research teams with no dedicated IT staff. As examples of open source linear algebra libraries, we have ATLAS, OpenBLAS and BLIS.