"There's services outside the kernel's control that may or may not do what the kernel/userland/user expect because they can be independently updated, and, oh by the way, they're really powerful" is simply a pain to deal with.
SMM is totally opaque and does whatever it wants, kidnapping the cpu and giving it back after a random amount of time if at all. Fuck determinism or meeting any sort of hard realtime requirements. It hides bugs and architecture details from the OS, and it often can't even be disabled.
SBI serves a similar role, without the opacity. OS can take requests to it, and even take over all its roles. It has been co-designed by hardware and software (operating systems and embedded) people across the industry, both companies and independent members. It's not even comparable.
Go read the SBI 1.0 spec, and the SBI 2.0 draft.
I'll stock up on my popcorn supplies, this will be fun to watch from a distance.
Why make an implementation in the first place? There's no reason to use anything else than opensbi.
That's also why QCSBI (or whatever they'll call it) won't be replaced by the kernel even though the architecture theoretically allows for it: That would be ceding control.
Also "This document identifies the Arm and industry standard firmware interfaces applicable to the Arm 64-bit architecture. They include the PSCI, SMCCC, UEFI, ACPI, SMBIOS, and DT interfaces. Requirements that are based on these interfaces are specified. In addition, various recipes are created to accommodate the various operating systems and hypervisors." (https://documentation-service.arm.com/static/627a75d3148af93...)
Two out of three "recipes" are UEFI-based.
--
As for RISCV, they're embracing UEFI, too: https://riscv.org/announcements/2022/06/risc-v-announces-fir... Note that the announcement also refers to SBI, which is RISCV's poor-man's implementation of x86 SMM, quickly becoming a required component on the platform because OSes call into that.