If you can't enforce that certain rules be enforced in a C++ program, you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.
> doesn't use any kind of static validation tooling, or CI build
Or, also: a review tool for rejecting stuff that is against the project's explicit coding guidelines.
In Java and .NET projects you can easily ensure that, and that is a common scenario in some of our customers.
The machines are provided locked down by IT with the project sanctioned tools, including the configuration for in-house Maven and NuGET repositories.
No native code compiler gets installed, servers are configured to disallow unsafe code.
Any library not available requires a change request to the IT team.
Stuff you don't want in C++ code can be rejected by a pre-commit hook which scans code. That header can't be #include-ed, that crazy operator can't be used, etc.
Also, with open source compilers, you can implement your own warnings. (Been there, done that; in the role of an embedded distro/kernel/toolchain person some years ago, I hacked g++ with custom warnings).
If there is something we don't want in C++, and it doesn't "grep" well, we may be able to diagnose its presence in the compiler and treat that as an error.
This is why on Solaris there is OS support via SPARC instructions to enforce bounds and valid pointer use, for example.
This is specially the case in the majority of enterprise software that doesn't use any kind of static validation tooling, or CI builds.