Since nothing in the C language prohibits bounds-checking for arrays, we can retrofit this to existing insecure languages rather than forcing all programmers to rewrite their software in some other language, which realistically won't happen for a decade or longer.
I don't know if things would be better now with more optimizing compilers, but I remember being somewhat surprised by this at the time, since you'd expect most of the overhead from passing fat pointers around to get optimized away.
There are many other examples of people trying to band aid and improve C's security history.
The biggest problem is that the developers that are supposed to actually adopt those practices don't really care, because performance trumps security.
Those that actually care end up moving to C++, or some other language, so we end up with this selection bias.
Thankfully they are being forced to change, as being 100% connected to the Internet does wonders to security.
Secure by default with option to turn those features off for performance, has been the way other systems programming languages have been designed since 1961.
That C culture is now being forced to change, because fixing memory corruption CVEs in devices that are permanently under security exploits attacks does not scale.