@Flater, you shouldn't change your answer "because I think differently", but only if you think I've made points which show the answer ought to be different.

I simply can't understand how you think the work can be divided up, and Bob does whatever the hell he likes, and somehow Frank is still going to find he can do his job (of persistence) later - and without readjusting Bob's design.

If you are routinely in the role of Frank, and you routinely work with various people in Bob's role, and if you never have to ask the Bobs to readjust their models to make them cooperate with persistence concerns, and if you're quite sure the Bobs know nothing of your job and couldn't implement persistence themselves, then...

the only explanation I can imagine off the cuff, is that they are following some kind of tacit constraint - perhaps a "best practice" that is rationalised in some other way, or something about the language used, or whatever - which makes their designs always compatible with persistence, and avoids the cases which would make your job extremely difficult or impossible.

The problem is that, when giving advice about these things, the tacit constraints also have to be identified and mentioned.

You're theorizing that developers might be using some kind of best practice in order to reduce the amount of tight coupling between individual layers even when they don't know the nuts and bolts of the other layer? You know, you might be onto something there.

Blatant sarcasm aside; that's the entire point of good practice. It seems to me that your observation is not distinguishing between following a best practice because it is a best practice, and concrete design that tightly couples one layer to another; you're almost reducing them down to "doing something so that it has a certain benefit". Which isn't incorrect, that is technically what they both are, but that is much too vague to be productive.

At the end of the day, the villain of the plot is tight coupling. Its main evil is that it makes future changes and maintenance disproportionately harder than it needs to be, which is by far the #1 cause of death for software projects. Good practice is not a form of tight coupling, it's quite the opposite. Good practice is still "doing something to achieve a particular outcome" but what is done, what it achieves, and the effort and risk involved in getting there are dramatically different.

Additionally, we cannot reasonably mandate every answer given here to always explicitly point out every bit of general good advice that developers live by. It would make reading any answer prohibitively more cumbersome. This answer is not to be taken as course material that builds up the reader's knowledge from scratch. It is a direct answer to a concrete question, and it should be judged as such.