That would create an explosion of code to handle edge cases that should never happen when interacting with the DB, or worse, pretending everything's alright and letting everything blow up in your face later.

So that you can cope with someone messing up a deployment and wanting to roll it back?

Let's say you avoid column restrictions in your db design, and you deploy some dodgy code that doesn't fill in a column correctly, now you've got heaps of dubious data cluttering your database, and apps failing because some precondition isn't being met. That doesn't sound like a good compromise to avoid headaches when updating a schema, does it?

So as ever, it's about making the right decisions on a case by case basis, and there is no 'one size fits all' for stuff like this.