Sure, but your solution supposes some kind of linking cop program overseeing the linking process, and who is going to keep the linking cop honest?

I mean dynamic loader is part of the base system and you generally trust the compiler and linker you build the program with. If any of those are malicious, you've already lost the game.

Asking a programmer to trust his own compiler and libraries which he can personally analyze and vouch for (static linking) is much different than asking the programmer to vouch for the dynamic libraries present on some given user’s machine.

Yes, the dynamic linker (/lib/ld-linux.so.2), which is one relatively short program as opposed to thousands of big ones. :)

The point is, there's simply no usecase to require or even allow the program to do IFUNC substitution freely on its own. A programming framework should not opt the developer in to capabilities they don't want or need. Much of C-likes' complexity arises from unnecessary, mandated capabilities.

IFUNC isn't used directly to patch the functions of another library here, it's just the entry point for the exploit code. IFUNC is used as opposed to other ways to execute code on library load because it runs very early (before linking tables are remapped read-only).