Re: The keys are not controlled by the owner.
"If UEFI was intended to protect from malware, the user could enter their own keys for what they want to have boot. This is not the current approach."
How would a piece of firmware tell the difference between a self-signed piece of software that the user wanted, and a self-signed piece of software that the user didn't want (i.e. malware). It's similar to self-signed certificates on servers - you need a trusted third party to verify (i.e. sign) your certificate else it's just a piece of software saying: "trust me because I say you can." Unless the code to be booted is signed with a key that the firmware recognizes (i.e. the device maker's key), then it can't know if the signature is valid. Yes - Secure Boot is designed to protect against malware. I linked you to a specific example of malware that would be blocked by it. There was an article on The Reg. here not long ago where someone had demonstrated how they were able to carry out an attack which was blocked if Secure Boot was enabled. It's downright bizarre that you claim it is purely a scam. Which brings us to this...
"So how did the malware get into the machine in the first place. It didn't get in through the boot process. The boot process is altered as part of the infection. What will happen is that the machine that gets infected will turn into a 'brick' and won't boot."
I gave you a direct link to an example piece of malware. You ask how did the malware get onto the machine in the first place. If you check the first line of the summary for that malware (or the technical name of it), you'll see that it is described as a Trojan. This means that the user has actively installed it, typically under the expectation that it is something else, e.g. porn or some such.
And nowhere in the description does it say that the infected device will become "a brick". Are you under the impression that Secure Boot will turn the device into a brick because of an infection? That's a good guess at what might happen if you haven't read up on it, but actually there are a range of options. First, note that this whole thing applies not just to the kernel itself but device drivers as well (which can also be infected). So you might for example, boot up in what used to be called "Safe Mode" with some functionality disabled allowing anti-malware software to re-install drivers or clean up infections. Also, typically, the system might start a separate repair or remediation process distinct from the normally booting OS which will again repair or clean up the infected system. There are all sorts of options, basically. Simply bricking the device and refusing to do anything...? Not by design, anyway.
And remember that the goal of modern malware is not normally to brick someone's device, but to either extract information or subvert their resources (e.g. for DDOS). I suppose if you're asking could someone write a piece of malware that infected not only the OS that ran, but destroyed the alternate systems put in place to recover from that as well with the deliberate intent of making the device a brick, I don't know. Maybe. But it would be a near-useless piece of malware to write and without profit. You can write a virus now today that goes and destroys an OS and user data with less privileges than are required to pull off a bootkit. So Secure Boot is not opening up any vector for attack that isn't already there.
Besides, you are aware that in the "bricking" scenario you have described, however unlikely, the user can just turn off Secure Boot, right?
"The way to prevent malware infection is at the point of infection. Fix the programs that are running, use qualified knowledgeable programmers instead of cheap off-shore labor. Take the time to test. Run boundary checking and fuzzing software against critical CIs.."
The whole principle of layered defence has just been discarded by you then? Firewalls should be disabled because no software on an OS will have a vulnerability that could be exploited? Suhosin and other server-level security should be disabled because no web-application written will have flaws in it? We should never scan for trojans because no user will ever install something without knowing what it does? We should never verify the signature of code we are booting because no malicious code will ever make it onto the device? That last one about verification of code - that's what Secure Boot does. I do not like your approach to security and I sincerely hope you are not involved in the field, though I get the impression you are not.
Honestly, you say you use Linux - one of the most secure OS's ever written, and yet you post arguments against a useful security mechanism that Linux can also take advantage of. What are you going to say when most Linux distributions are also using this security measure? Are you going to write angry posts about how CentOS or Ubuntu Server should not have this security measure?