In 20 years of programming I maybe seen one or two times a large application switched database engines and I've never seen a client want to run his/her web application in CLI...
The art in programming is to decide whether you need that abstraction or not.
It's that' the high-level business logic does not have any low-level unrelated persistence code in it.
I would still kinda consider that. But the solution wouldn't be to create some massive abstraction. Instead I'd try to separate logic from database access code. I.e. avoid reading data from the database while you are in the middle of some calculation, or in the GUI somewhere. If you need the data do it beforehand and pass it in a generic data format.
Abstracting away the database also makes it easier to write unit tests for your business logic.
We. Never. Have.
And even if we did... its still under source control if you really want to dig it out.
And I find that removing dead code often unlocks further improvements that become obvious without the noise.
Even if the functionality is needed down the line, it tends to require massive rewrites to catch up.
However, I definitely see value in making code easy to throw away. That's something slightly different than making something easy to swap out. Entire front-ends being re-written is something I've seen a couple of times. But when they were super-glued to the back end that was very, very expensive to do. They were hard to throw away. I think clean separation between boundaries means when you want to throw something away you can. Doesn't mean it will be easy, but a heck of a lot easier. You don't necessarily always want to replace certain things either, sometimes you just want them gone.