UEFI is poorly understood by approximately everybody who doesn't work directly with it and it's frustrating to see so much misinformation out there.

UEFI does not mean that there is a huge binary blob that does not run open source. UEFI is a spec. It defines many steps that must be taken to boot in a compliant way. Large portions of the code that runs in UEFI compliant systems in the wild today are in fact based on an open source 'core' available on github. It is entirely possible to perform a UEFI boot on an entirely open firmware stack, though this tends not to be done. Large silicon vendors like to keep their silicon initialization code proprietary and secret, and they often 'require' tweaks to the open source version of the UEFI 'core' to meet their needs (read: it's seen as easier/cheaper/more-business-friendly to fork the open source core and sprinkle two or three changes throughout and keep the result closed), but there's no reason it needs to be that way.

The author is wrong - there is no 'UEFI kernel' running at any ring after boot. UEFI leaves some code and data in ordinary, OS-accessible memory which can be jumped to and run by the OS if desired to perform some UEFI-related task like setting a boot variable. This code is not protected or hidden or in a special ring and does not require any special steps to invoke. It just sits there waiting to be called and can be modified or deleted if the OS chooses to do so.

SMM is actually a special ring with its own privileges, but there is nothing baked into UEFI which requires using it or leaving code running there. UEFI is extensible and so some platform performing a UEFI boot can leverage a hardware feature like SMM to maintain some control over a platform, but that requires the firmware developers to go out of their way to do that and it can only be done on hardware equipped for it.

But you know what? UEFI is not at fault there. If a platform performed a UEFI boot without touching/configuring SMM at all, then the OS or the bootloader could do the same thing. The hardware capability exists and is accessible by ring 0 until somebody flips a switch to remove that accessibility.

Proprietary, insecure software is a problem. Making firmware fall into that hole is really bad. But UEFI doesn't make that happen. UEFI is just a way of booting that doesn't specifically disallow it, because it's designed to be flexible and extensible and powerful so that a lot of needs can be met. It's completely possible to put together a firmware image which is UEFI compliant and goes out of its way to disable SMM (or any other hardware feature), and boot to an OS that wipes UEFI traces from memory if it feels like it.

Something like Intel's ME existing as an option for businesses who want it is fine. Injecting it into every platform and making it roughly impossible to disable is not. Either way, UEFI is not implicated.

UEFI is not the bad guy. Those who ship UEFI compliant systems which happen to suck are the bad guys. They do it with UEFI, they did it before UEFI, and they would do it without UEFI.