This is not only about frameworks and ORMs, it's about refusing to comprehensively understand stuff before you use it or change it. It can be any abstractions, even (usually) the ones you created by yourself.
It's easier to add a special case check, than to read through the codebase to see if it's even needed, or, God forbid, to refactor in 5 places so it's not needed (it might break sth else!!! I would have to read and keep in memory the whole control flow of the program!!).
Programmers have to do dozens such decisions every day, so after a few months if they go the easy way too often it adds up and creates chaos.
I've done this myself, and seen this done by younger programmers. It's that crucial skill of stepping a few steps back and looking at the code as a whole.
I've seen a great compact example recently, one of the students I supervised wrote sth like this:
List findBySurname(String surname) {
List persons = session.find(surname);
if (persons.size() == 0)
return null;
return persons;
}
...
List persons = findBySurname(surname);
for (p : persons) {
p.doSth();
}
The student wrote both methods, and got rejection from tests because of NPE. He wanted to fix it by adding
if (persons != null) {
...
}
:) this example is easy, but in more complex situations it's easy to do the same, and it adds up. This is one of the reasons I dislike OO programming (especially the kind where you hide everything behind a few layers of interconnected objects). Because it makes it harder to understand what REALLY happens on the data level.