Thanks, Microsoft, you pushed for that, now we'll have another 20+ years of legacy UTF-16 strings

It's actually worse, because it's not even UTF. It's just stupid UCS-2 limited to 16 bits. So it's a mistake on top of a mistake.
The UEFI code signing structures are also MS-derived, to the point where the structure members start with 'win'.

Thanks, Microsoft, you pushed for that, now we'll have another 20+ years of legacy UTF-16 strings

There's two different 16-bit unicode encodings:
UCS-2 uses two bytes per character, and can thus encode codepoints up to 65536 (the Basic Multilingual Plane, BMP - also known as plane 0).
UTF-16 uses two bytes per character, but also has escape codes that can be used to encode 32-bit codepoints.

UEFI uses UCS-2. On the positive side, it's easy to work with (strings take fixed amounts of space, and it's trivial to cut/paste at positions that leave valid strings), and the lower 64k of unicode still covers enough to cover all modern languages. It's also got decent language support - even C has wchar (for a 16 or 32bit single character) and supporting functions.

On the negative side, it can't encode the higher planes of unicode (which would allow e.g. using unicode symbols instead of bitmaps ; the emojis are encoded in plane 1), and it's considered obsolete, superceded by UTF-16. There's also some extensions to the CJK range; I don't honestly know if those are in daily use or if they're historical variants for scholarly purposes.

Everything considered, UCS-2 isn't a horrible choice for something like this, since it's simple to work with while still covering all the characters needed to present text in currently-used languages (modulo the CJK extensions - but I suspect those aren't required for decent enough everyday Chinese/Japanese/Korean.)