The threat you identified isn't special to GRUB or even bootloaders. Any EFI executable could potentially be "hiding" a malicious bootloader, or some other malicious payload that mucks with the way Windows boots up. I think you'll deal with this potential threat exactly one way: if you find out a previously-signed EFI executable is doing bad things, you'll add the signature associated with that executable to the "forbidden list" (essentially revoking the signature), and you'll go after whoever submitted that executable for signing.
That doesn't necessarily help you if OS-present malware modifies the loaders and the kernel. On the next boot you could load a modified kernel, which isn't going to be detected because you'll also have modified loaders. But, a lesser-known fact about UEFI secure boot with Windows8 is that Microsoft's OS loader is going to be signed with a different key than all other EFI executables. While I don't know exactly how its intended to work, its presumably intended to help block the sort of attack I think you are imagining. But, at the very least, GRUB can't directly load Windows. Instead it would launch the Windows 8 loader, and the UEFI BIOS should verify the signature at that stage. Presumably a bootloader like GRUB could be modified to directly load Windows, but that might be enough to land you on the forbidden list if someone catches you.
I don't know. All that's basically just a guess on my part.
I think you're absolutely right though that there's a tension between security and flexibility here.
You make an interesting point about service processors. Generally speaking, it should be difficult for malware to use that vector, since service processors (should) authenticate any requests (using a digital certificate, or at least a password). Still, a strict interpretation of Microsoft's requirements say that physical presence is required, and remotely changing a BIOS setting via a service processor isn't physical presence. Will OEMs write their BIOS so you can't change that setting via something like AMT? Maybe. I don't really know. I honestly don't see a compelling need to be able to turn it off remotely, so it seems like a bad idea to let it be remotely accessible by any mechanism, including a service processor. If you're running Windows, the only reason you might want to turn off secure boot is to use an old add-in card, in which case you're already physically at the box. If you're running Linux, and they don't get their act together to play nicely with secure boot, then you're just going to turn off secure boot when you initially set up the system.