I think GP is saying that unit tests for such dynamically-dispatching code will want to be able to inject older CPUIDs, so the compatibility fallbacks have test coverage. If CPUID is a native instruction, it's harder to inject a fake value.
I'm not sure I find this compelling though. It's easy to make your own CPUID function that doesn't actually call "CPUID" in a test build.
Huh? My impression was CPUID was exactly the opposite: using it properly allows ensuring compatibility on older computers while still getting maximum performance, since one can dynamically dispatch to an implementation that uses only what is supported. (E.g. switch between an SSE2 version and an AVX version.)