Schemaless databases move the integrity checks up into the middleware, which I dare say is a more flexable place to have it. Most ORM libraries have integrity checks so the db checks end up being redundant and more difficult to change. I too have been saved on occasion by such 'redundant' checks, but over all I find its easier to manage the structure of data when its kept in the middleware. Keep the storage layer as simple as possible with a focus on consistency, availability, and partition tolerance (CAP).
While ORM level validations are nice to have, they are in no way substitutes for database level constraints. Just relying on ORM level validations is like saying "hey I'm doing error checking in my javascript code and therefore checking for errors on the server side is redundant and unnecessary". It's not, DB level "redundant checking" is worth it. All it takes is for one guy to "just quickly try something" in the db by trying to manipulate it directly without the ORM layer to have your db end up in an inconsistent state. ORMs have their own conventions on how they handle validations which maynot be completely obvious to a new developer on your team who is not familiar with it, whereas everyone understands how db level constraints operate. I'd rather put a few lines of extra code at the db level to make sure the data is safe than risk having the db end up in an inconsistent state, you are not only doing this for the customer but also for yourself. You don't want to be the developer who has to go in and figure out why certain queries are not returning the correct results after your db is in an inconsistent state.
