It's not surprising that they use static types in C++, but it's not about safety. It's about knowing the size of everything at compile time. Dynamic typing requires moving more towards the "interpreted" side of languages and incurring the performance cost of that.
The contradiction is when the veteran SWEs I work with say we use C++ instead of Python for the added safety of compile-time type checks, treating dynamic typing like a bigger risk than memory trampling (never mind that Python has type-checking too if you really want it).
For very large projects static types in C++ are a lot safer than Python. For simple projects I agree with you, but as you get over 50k loc Python becomes hard to manage, while i'm work in 10 million lines of C++. Sure it takes more effort, but at that size C++ is a lot easier to manage.
C++ does have issues. However few languages can handle complex problems well. (Rust is very intriguing for the possible ability to do things at the same scale)
10 million C++ lines is 10 million chances for you to misuse memory and cause your entire program to behave unpredictably, from simply crashing to writing garbage directly into your database. Imagine you're on a team of 8 and find one day that your DB's indexes were mysteriously corrupted, what do you do next? It's happened here.
If you use the wrong type in Python, you get an unhandled exception failing to find a property or something, that's about it. Maybe there's a contrived scenario where it'll succeed in a wrong way, but again that's a smaller blast radius
The likelyhood of Python crashing is a lot higher as it is much harder to know you didn't break your error handling path someplace that isn't tested. C++ sometimes has memory issues, but not nearly as often as Python has problems in the error paths.
Python is exception-based, so it's easy to avoid a crash. Say it's a webserver, you catch all exceptions around each endpoint and give HTTP 500 if it's not something you understand to be a 4xx. Exceptions are nice in that you either explicitly handle them or the caller will.
C++ has exceptions too, but I've never used them, so idk. The abseil statuses end up being used like DIY exception handling, and it's ok but a bit easier to mishandle something than in Python. And a segfault cannot(? or shouldn't) be caught and will crash the whole program.
I am not writing a web app, I'm writing an embedded system. Catching an exception is nice, but I still need my code to keep working, which memory leaks do allow, generally for a long time. yes we have had some 'memory scribbler' bugs that were a pain to track down, but they are very rare compared to changing python code and missing to make the right change to an error handling path and now Python unwinds to main instead of handling the error correctly. Note that I'm saying Python errors of that nature are more common despite comparing 50k Lines of Python to 15m lines of C++.
For short programs Python works great, but it doesn't scale to large programs.
You can comfortably write a large web app in Python or similarly in JS, and people do. For embedded, it's already out of the question for other reasons. And you probably don't want exception-based handling in embedded, yeah.
The contradiction is when the veteran SWEs I work with say we use C++ instead of Python for the added safety of compile-time type checks, treating dynamic typing like a bigger risk than memory trampling (never mind that Python has type-checking too if you really want it).