Yes. C/C++ are inherently predisposed towards being buggy and unsafe, relative to more modern languages. They trade runtime checks for minimal runtime overhead (and I'm not saying that's a bad thing), but they don't make any effort to assist the programmer in the area of code correctness. Even the few compile-time systems in place to prevent programmer error (i.e. the type system) is pretty easy to circumvent. Take for example assigning one struct to a (completely different) one (which is an illegal operation);
type1 t1;
type2 t2;
t1 = *(type1 *)
It's as easy as that to completely subvert the type system. This is because C assumes the programmer knows what they're doing/is always right, which more often than not is not the case. However, if as you say, people who write unsafe code "shouldn't be allowed near any programming language anyway", then we'd have precious few (i.e. zero) programmers. You can never tell that there's a security vulnerability in your code until it's been found, and you can never conclusively prove your code to be security-hole free. In addition, very often in industry software security is an afterthought, as it's not as tangible as implementing new features. As a result, no one spends any meaningful time on detecting vulnerabilities (which can be very subtle). This is why having a language that makes it easy to write good code and hard to write bad code is so important. C will always have a place in embedded systems and OSes because of its flexibility and speed, but it's high time that we moved away from such low level languages in other software contexts.