The TPM controls the rate-limiting. A compromised OS shouldn't affect it. (Otherwise a live CD could compromise your disk encryption, as the encryption is usually done at the OS level, not in the BIOS/EFI).

Perhaps not rate-limiting, but on the i-phone, it was about circumventing the limit of 10 tries.

Besides, doesn't secureboot block an unsigned live-CD? Otherwise, I don't see the point of secure boot past vendor lock-in.

It is supposed to prevent boot level malware or people otherwise compromising the device. Implemented correctly, it can be beneficial to security. As an end user, I like having a TPM, and I like having boot level protection measures. I wouldn't trust my life to them, but after seeing indictments/FBI testimony, they seem like they are enough to deter many attackers.

The whole "only applies to RT devices" was a bit shifty looking from MS, though. Fortunately the broken Windows on ARM model died.

Edit: I'd also note that, e.g. console gamers love this stuff. It allows them to pretty much rely on others not being able to cheat very well.

So does it validate the bios/uefi firmware? Which then in turn can be setup to validate the OS (or not to validate it?)