in this context, it's not vague nor likely to be uncommon.
for the purposes of mitigating the vulnerability in msmpengine, what matters is that msmpengine has cfg enabled. whether other arbitrary programs on your computer have it too is not relevant to this story.
cfg works like this: when a process has cfg enabled, the windows kernel will maintain a list of all valid indirect call targets for it, and then validates all indirect calls against this list. if validation fails (because the process attempted a call to an invalid target), the kernel terminates the process.
obviously, this requires kernel cooperation. this was introduced in windows 8.1, which means windows defender on windows 7 can't use cfg there.
cfg raises the bar a little in making it harder to obtain remote code execution from simple memory corruption, but doesn't make it impossible.
The function count should be non-zero, the Control Flow Guard dll characteristics flag should be set, then the CF Instrumented and FID Table Present guard flags should be set. Be aware that this filters out a lot of other details and misrepresents the full list of flags.
We're only talking about one exploit in one program. CFG doesn't have to be "common" to be relevant, it just has to have been used in that program, which it must be or it wouldn't have been mentioned.
Edit: Control Flow Guard. So software which is compiled with this specific flag in VS 2015+ isn't affected.
That seems vague and unlikely to be very common.