The core issue here is the on-by-default requirement for consumer hardware coupled with the specs limitations which prevents a mult-vendor trust chain.
Secureboot as a concept is not a bad thing. The policy surrounding how to enable secureboot for consumer devices needs some iteration however. There is absolutely nothing wrong with an off-by-default secureboot even with the current specification and limitations. On-by-default, has some definite challenges, and MS's certification process requirements brings these challenged directly into the forefront of the discussion.
Even with an on-by-default scheme, if users can disable secureboot to regain access to a system that has been impacted by a key revocation I really don't see a fundamental problem. As long as users are not locked out of the firmware config screens to disable secureboot on the hardware they purchased, a 3rd party revocation process is best described as a very stringent notification about a potential system compromise. If users can disable secureboot they do not lose access to their systems even after a key that their current configuration requires has been revoked.
In fact I'd wager that once the security benefit is digested more widely large institutions like the US Department of Defense and the State Department and even municipal power companies will be making heavy use of secureboot with their own signing keys on a lot of critical infrastructure and even desktops and laptops...so they don't even have to implicitly trust any Vendor (including Microsoft). They'll use the firmware reconfiguration to the fullest to load their own keys on their hardware and then self-sign binaries and to control the revocation process from end-to-end.