Because here it is trivial to make them backwards compatible, by just using a PRE() and POST() macro which are empty pre-C++26.
The contracts_assert is either static or runtime, which the compiler can decide. Better than explicit static/asserts, which are either unnecessary or costly.
I think defaulting all assertions to enforce would've been better with an optional soft modifier (ie "soft pre(foo)" ), as it is now it's just always assert in a trenchcoat.
What the contracts committee should do is go back and revisit the entire thing with regard to correctness only and not performance. Do the same thing as in Eiffel (not at all easy), which might mean a change in the core language semantics itself. This would be a huge change but maybe acceptable for the benefits it brings. There should only be a simple binary compilation switch between the two versions of the language.
I think the above is doable but it would be a new version of the C++ language and with changes to the toolchain all the way to the binary metadata and ABI. So you would have a "Raw/Performant/Backward compatible C++" and a "Safe Managed C++ with contracts". They could probably interop like Rust does with "unsafe" keyword.