Like any language feature, you have to know what you are doing.
The correct reasoning would be to recognize that certain language features make entire classes of bugs impossible. For example, in my Rust projects, I never have to worry about null pointer errors. Sure, there might be other types of bugs in my code. But at least I don't have bugs due to nulls. Also, there are no data races in my code—yet another thing I don't have to worry about thanks to the design of the language. (I'm not saying Rust is perfect. I'm just using it as an example.)
Other times, the need to have direct hardware access from the BIOS on up cannot be avoided.
The bugaboo is the quest for the One True System that is all things to all people.
Emacs is as close as we get to that Nirvana.
What does bother me is where you detect the bug.
Is it at compile-time?
Is it at run-time through a crash?
or is it months later after you notice that many of your users seem to have January 1st 1970 as their birthday with no way of recovering the lost data.
But hey - at least stuff kept running. Right?
This year has already seen CVE-2022-25636 (heap out-of-bounds write), CVE-2022-27666 (buffer overflow), and CVE-2922-0847 (uninitialised memory). Three vulnerabilities in the Linux kernel, in pretty important (and therefore, presumably, closely scrutinised) bits of the code base. And this is the Linux kernel, arguably the most important open source project in the world, worked on by some of the most skilled developers out there.
Everybody writes bad code, and everybody misses bad code on review, even in the really important bits, even when they’re well-known bug classes. Criticising a language for leaving these foot guns lying about is perfectly reasonable, and it’s important we talk about avoiding those languages wherever possible.