Most programming languages are written in C, which doesn't.

Fairly sure that was OP's point.

Secure string handling functions like strlcpy() and strlcat() do have bounds checks. Not everyone uses them sadly.

And that again, is the point. That stuff should be built-in and almost non-negotiable. It should be a lot more work to do the unsafe thing (see: Rust).

They are negotiable in Rust too. Just use the unsafe keyword everywhere. If you want to use a language where they are non-negotiable, use JavaScript.

Secure string functions are built into C these days. The older error prone ones are as well. You can ban the older functions from code bases, but it is hard to justify outright bans for all of them. If you ever audit string function usage in a non-trivial codebase, you are likely to find instances where the error prone functions are used in provably safe ways and leaving them alone makes sense, such as when constant length strings are used with constant length buffers. That is what I discovered when I audited the string functions used in OpenZFS with the goal of removing all uses of the older string functions. I removed most of them, but there were a few instances where the safety was easily provable that I left alone, since slowing down code for not even a theoretical security benefit is silly. After my patches, a few string functions were then banned from the codebase with a build system hack put in place to break the build process if someone tried to reintroduce the banned functions.