Back when I was working on Django codebases, I saw almost no use of `full_clean()`, largely because some validation was performed on `save()` (by virtue of bein

Back when I was working on Django codebases, I saw almost no use of `full_clean()`, largely because some validation was performed on `save()` (by virtue of being database constraints, e.g. non-nullability) while other validation was not, and there was no indication in the APIs which was which. In a world in which Django applications were always written by people who read and understood the docs in full, I would totally agree with you about these criticisms. But I've never had such an opportunity outside of my own projects. I've only dealt with codebases that were written with falty assumptions, enabled by Django's choice to hide some but not all tricky work from its users. By then the database constraints would be incredibly painful to add since there was lots of data already violating it, and switching global defaults like ATOMIC_SAVE were nearly as bad since code had widely relied on other behavior.