On topic: does the open-source Coreboot fare any better here? (I hope it does; the article does not mention it.)
The most typically used payload is u-boot: https://docs.u-boot.org/en/latest/
u-boot supports specifying splash screens via "splashfile", but it seems only bmp and maybe some raw image format are supported: https://github.com/u-boot/u-boot/blob/2f0282922b2c458eea7f85...
In other words, no support for png, which this exploit uses :). That doesn't mean that coreboot/u-boot aren't written in C though which is a language known for its vulnerabilities.
C is not known for its vulnerabilities, it's known for being fast, portable, and low on abstractions. It's a perfect fine language to write this kind of code. There are techniques like fuzzing and using things like valgrind that can catch invalid input and memory issues quite quickly.
C is not known for vulnerabilities, it simply makes it easy to shoot yourself in the foot. The tooling exists to improve code safety, but generally if you don't do anything crazy, nothing crazy happens.
Lasers, chainsaws and pressure washers are all easy to hurt one's self with but I wouldn't say they're known for creating injuries. It's more like people are stupid enough to hurt themselves with tools regularly.
It's not hard to check a value before dereferencing or freeing it. It's hard to remember to do it.
Chainsaws are so known for accidents they come with warning pamphlets instructing you in how to use them in ways that minimize the risk -- including recommendations for wearing reinforced chaps to protect your legs.
So, following your comparison, it should be perfectly valid to apply a warning sticker to C that says "Warning: Known to state of California to cause data corruption and accidental code execution".
Are we gonna include warnings for SQL injection risk? This is a stupid premise.
No, we've moved to calling conventions that avoid SQL injections: bind params. That argument speaks for minimizing use of C, not in its defense.
It's okay to admit you don't like a programming language.
I'm anticipating the time when Rust and Zig will displace C as the default language for writing hardware-interfacing code. It's not going to happen tomorrow, though.
With payloads, some are more at risk than others. edk2 might run into issues here, grub2 has tons of features where stuff like this might hide in, other payloads (e.g. ChromeOS' depthcharge) are more limited in their functionality and therefore in their attack surface, too.