Description:
The CPU dispatcher checks CPU vendor_id for GenuineIntel, and if it is anything else, disregards available instruction sets and falls back to SSE1. Previously existing workarounds have shown this not to be a technical incompatibility, but a deliberately kept stunting of competition. Descriptions can be found in https://en.wikipedia.org/wiki/Math_Kernel_Library#Performance and its sources, which also provide test data. This is mainly a problem because the library is the defacto standard in scientific computation and a common dependency.

Additional info:
* package version(s)
Any. As of Update 1 2020, the only widely confirmed workaround via an undocumented debug environment variable ceased to work.

* config and/or log files etc.

* link to upstream bug report, if any
If you want to call it that, the Optimization Notice displayed on each subpage of https://software.intel.com/content/www/us/en/develop/documentation/mkl-linux-developer-guide/top.html

Possible source of hints for a patch:
According to https://www.extremetech.com/computing/302650-how-to-bypass-matlab-cripple-amd-ryzen-threadripper-cpus , the old patch provided for the "cripple AMD" function in the intel compiler at http://www.swallowtail.org/naughty-intel.shtml#patches also works to remove this problem in mkl, but since the patch is from 2005, for a different product, unofficial, and according to https://www.agner.org/optimize/blog/read.php?i=49&v=f#1020 suspicious of shipping malware, it would have to undergo close scrutiny before being used or adapted, but could potentially be the base for a solution.

Steps to reproduce:
Direct comparison showing this to be an avoidable and intentionally kept problem ceased being easily possible with the removal of the only widely confirmed workaround in Update 1 2020, but the various comparisons done beforehand speak for themselves. Possible comparison by usage of the patch at http://www.swallowtail.org/naughty-intel.shtml#patches would have to be preceded by close inspection of said patch and/or testing in a specially secured environment.
The only thing readily confirmable without recourse to existing test data is that mkl works substantially worse on AMD than it does on Intel, by comparing execution times on up to CPU identical systems, one with an AMD CPU, and the other with an Intel CPU of comparable specifications, and both as modern as possible to see maximal effect of unused instruction sets.