Not sure what conclusions to draw from that, but it looks like ARM support was finally made first class this past August: https://github.com/ispc/ispc/blob/cf90189/docs/ReleaseNotes....
I think it might be difficult to purposefully cripple AMD in an open source project.
It's not as explicit as it has been in the past, but the CPUID checks for very specific feature sets aligned with particular Intel models may not match AMD models, producing worse code on AMD models that support featuresets above baseline AVX2:
https://github.com/ispc/ispc/blob/master/check_isa.cpp#L106-...
That said, I don't assume malice here and I haven't investigated thoroughly. Most likely they just want to support their own silicon well and that's what they know. It's possible they would accept similar support for AMD µarchs in the OSS project (or maybe not).
I wouldn't draw too much inference from the ARM example, as I don't see ARM as an Intel competitor. AMD, on the other hand, is currently very competitive with Intel.
Interestingly, Intel people don't necessarily have the information to optimize for Intel CPUs even, and the hardware may not tell you. It's really complicated and messy. An example that's relevant to linear algebra is figuring out whether to use FMA, e.g. https://github.com/jeffhammond/vpu-count
You can compare it to other detection functions - one relatively easy to read, non-vendor biased example that does dig into all the extensions is this Go implementation (not mine): https://github.com/klauspost/cpuid/blob/master/cpuid.go
Zen1-2 should land on the "AVX 2 (Haswell)" path in the linked excerpt -- they have AVX/AVX2, F16C, OSXSAVE, and RDRAND -- which is the best ISA without AVX512 implemented in the compiler. That's entirely reasonable on Intel's part.
(I don't know why they look for RDRAND in a compiler, but whatever.)