The idea of secure boot is to ensure that it's as difficult as possible to run untrusted code before you've set up your desired trust chain. If you can launch untrusted code within the Linux kernel then it's a simple matter to use that as an attack vector for Windows - rather than writing your malware from scratch, you drop a copy of the exploitable kernel in the EFI system partition, provide a trivial initramfs that gets you into the kernel, pass in the NT kernel and appropriate drivers, set up the loader parameter block, set up some new page tables and jump into the Windows kernel. Of course, rather than just booting it you've taken the opportunity to compromise it in some subtle way. Windows boots slightly more slowly than usual, but there's no reason for most users to notice - and worse, the malware checking code that would normally be able to rely on the kernel not having to be compromised is now unable to do anything useful.
So that's the why - breaking the trust barrier results in revocation. The how is a little more difficult. There's two ways you can revoke binaries. The first is to add an update of the specific SHA256. That makes sense in many cases, but probably isn't the best choice here - any older kernels are presumably also compromisable. So instead you just revoke the individual signing key and sign your kernels with a new one. How will that scale? Great question. We'll find out.
And yes obviously there's the risk of implementation flaws. The cryptographic model in use is believed to be sound, and we assume that Microsoft have learned from their mistakes with the Terminal Server key. Is that a guarantee? No. But then SSL isn't guaranteed to be safe either, and people still rely on that. Proving security is hard.