It's not uncommon to switch from one database to another (say, MySQL to Postgres). Django's DB abstractions keep you from having to really worry about what actual database you're running on; unless you had hard-coded dialect-specific SQL somewhere, you just flip a couple settings and now you're talking to the other database.

Same for changing replication setups, for changing authentication mechanisms, for changing logging setup, for changing how you do caching... all of these are things that can and in the real world do change, either from testing to production environments or over the life of a production application.

So it makes sense to abstract those, and the abstraction is backed by "these are things people have really needed to do frequently".

What I have a problem with, and what I criticize as overabstraction, is when someone then comes along and says "well, what if you replace the persistence layer with something that's not even persistent, like volatile memory or stdout (which is actually logging, not persistence, at that point -- a confusion of concerns!)" And then they write a blog post explaining how really you should keep abstracting to the point that the code can "persist" data to those things.

And that's why I say that the examples almost always feel incredibly contrived; it's like somebody didn't know when to stop, and just kept abstracting everything they could find until they ended up with an overengineered mess. Static/dynamic actually has very little to do with this, since even languages that do static typing in overly-verbose and un-useful ways can handle the kinds of abstractions people actually use.

So I don't see a point in re-architecting for these weird contrived hypotheticals, which always seem to be the focus of whatever we're calling the indirect-abstraction-for-everything pattern nowadays; it produces code that's more complex than necessary, has more layers of indirection (and hence bugs) than necessary, and doesn't actually gain any utility in the process.