If it doesn't "prevent" people from checking in code (in the strictest sense of the term) that breaks lots of other code, it certainly does some combination of slowing them way down, notifying other people way sooner, or forcing them to be a great deal more skilled in how they check in their breaking code (in the "if you make something idiot-proof, someone will build a better idiot" sense of skilled).

It's not perfect, but it's better than most of the alternatives, and perfect isn't actually on the table anyhow.

True. Code reviews and standards are the tools to use in this case.

I've found that code reviews are one of the best ways to increase code quality. Even just talking with other developers about why they've done things is helpful in thinking about simpler options and keeping things closer to the architectural vision.

Just questioning the implementation is enough to improve quality. Plus it helps people grow without putting them on the spot (if done right).

Who cares about poor unit tests in this case? It's all about the INTEGRATION tests that run on CI to make sure your bad developer can only fuck their shit up and not anyone else's. And if you have bad developers building your integration testing framework, you have bigger problems.

If someone checks in code that breaks a bunch of tests, then you know right away. And the underlying assumption is that tests are written by multiple people with varying degrees of quality. Can bad code sneak through the tests? Of course! But to say it does no good at all is wrong.