This is kind of weird in that it's exploiting a vulnerability in the Windows bootloader, but once exploited it's pivoting to using shim+grub (edit: apparently it's not actually grub, it's their own bootloader that's just called grubx64.efi because that's what shim boots by default). There's no absolute requirement to do this, but it's presumably easier to implement their full payload in grub rather than getting it all running in the context of the Windows bootloader. This means it probably doesn't work on the Secured Core PCs that only ship with support for the Windows signing key (but also it can't be used to attack Linux systems that remove trust in the Windows key).

This pivot means that the keys measured into PCR 7 of the TPM will change, which breaks the Bitlocker policy, which is presumably why stage 1 disables Bitlocker before exploiting the bootloader. This means it's also detectable using Remote Attestation (I think Microsoft's Device Health Attestation ought to notice, but haven't verified it), which is nice for all 3 of the people who've rolled that out.

In terms of why the known vulnerable bootloaders weren't already revoked - I have no inside knowledge here, but my guess would be the impact on users with existing install media (including factory restore images). We've revoked a bunch of vulnerable Linux bootloaders, but the level of pain involved in revoking a Windows one is almost certainly way higher.