AMD processors have much the same backdoor-"management" coprocessors. Just about the only processors without this stuff is your own softcore design running on an FPGA.
Okay, but that doesn't really bother me; running arbitrary payloads is the point of a bootloader. The only reason I would be worried by UEFI on RISC-V is if the UEFI firmware in question stays running in the background after the OS boots, and isn't properly inspectable. That might be the case - I have some vague notion of UEFI providing post-boot services, and for all that the EDK version is FOSS you could certainly make a closed version - but I'm not seeing any reason to panic just yet.
A malicious actor can do a lot of things in UEFI, but they can't decrypt my disk, they can't boot into my OS, and they can't mess with my userland environment. If Johnny Blackhat fancies a game of Doom over TTY on my desktop's UEFI environment, he can be my guest.
It doesn’t sit on the network (unlike the ME) so an attacker needs to have access to the host already to be able to exploit any vulnerabilities on the PSP.
This is not about the management engine. Microcode is part of the actual core processor itself, but an updatable layer. One sort off correct mental model might be to think of x64 hardware as being a RISC-ish processor that runs microcode that runs your code.
I think in the original analogy, the actual robbery is just used as an event which may occur without our knowledge. Your analogy is better, the mapping makes more sense.
Something like: The locksmith has made a copy of your keys without notifying you. They could hypothetically use those keys to enable a robbery, but you won't know definitively either way until you find something stolen. But it is a pretty weird thing for them to do, right?
https://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf