Based on JF Bastien's 2018 CppCon talk:

Many (most?) integer overflows are bugs—not just because they open the door to undefined behavior, but also because, even if the overflow was defined to wrap, the code would still be wrong.

Your compiler and other tools could help you find these bugs by trapping on overflow, which is allowed because overflow is UB, so the compiler can do whatever it wants. If the behavior were defined, the compiler wouldn't have the flexibility to help.

Thus the standard declares that the representation shall be two's complement. It does not require define how the arithmetic operations should behave when there's an overflow because there is no good solution that works for everyone.

If the standard were to define overflow behavior, how should it define it? Many would want/expect wrapping, but others would find trapping more useful, and saturation can be useful in several domains. Since programmers can make C++ classes that behave like arithmetic types, you could have a library of integer-like types that implement whatever overflow policy you like. If you know that your code will never overflow, why should you pay the overhead of any of those behaviors?