"Undefined behavior" is a quirk of the C++ ISO standard legalese, not some property of computing or of the C++ language.

Briefly, the C++ standard defined three classes of stuff that isn't covered by the standard:

Implementation-defined behavior - "behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents".

Unspecified behavior - "behavior, for a well-formed program construct and correct data, that depends on the implementation".

Undefined behavior - "behavior for which this document imposes no requirements".

So 'undefined behavior' is stuff that isn't mandated by the standard and also may or may not be an error.

Some UB stuff is bugs (like accessing arrays out of bounds), some isn't bugs but just processor/OS dependent stuff that is out of scope of the C++ standard. (Like what happens when integers overflow.)

In short, the existence of UB is a good thing; having a standard that clearly states what is part of it and what isn't is vastly better than a standard that mandates too much or is too vague.

(And it goes without saying that having no standard at all, like is usual for other programming languages in 2019, is worse in every way.)

If you were doing software development in the 80es when C++ was born, you wouldn't be asking this question. You'd either choose a language that allows undefined behavior and write a program that completes the work today or a language with all possible runtime checks and a program that completes the work sometime next week.

Undefined behavior is stuff that is incorrect and must not happen (e.g. out of bounds access). Making it explicitly undefined helps writing efficient implementations.

So not only undefined behavior has not hindered the success of C++, it's probably one of the things contributing to its success, in particular its success in developing embedded and safety-critical systems.

If you write a program for which correctness is particularly important (e.g. a safety-critical program), you must ensure, through tests, proofs, magic, etc. that you don't have any incorrect behavior. Which might be undefined, but again the problem is that it's incorrect, not that it's undefined. If you're flying at Mach 2 and an out-of-bounds read or write happens in your flight control software, it doesn't really matter that much whether you get "undefined behavior" (i.e. read or write "random" address), a panic, a log message, a popup window, etc. The safety is compromised by the fact that you did an incorrect operation, not that the operation is undefined.

Now, if you want to write a music player or something like that, it does make sense to use a language like Python, Go, or whatever might give you more guarantees than C++, because realistically you're not going to write a proper test suite for it.

Someone has to write the operating systems and debuggers directly for hardware, including microcontrollers which don't have various cpu facilities/guarantees.

Because it is quite a bit too obvious?