The point is that requirements change. Every successful system needs to be maintained and extended for years, if not decades. You don't know what requirements will emerge during that time. That's why it's important to manage the dependencies of the code to keep it flexible.
That's an investment! In my project we use old, limited functionality, buggy domain store (something ala Hibernate, but I wish it would be Hibernate). I would love to switch to Hibernate. The singleton we use to access our SQLManager is very small part of the problem. Even if it would not be singleton, still the whole system depends on custom relation mapping file, and API.
I think what you suggest is a upfront system design. That is one has to think through all design issues that may change and do it very flexible. Make big investments in code flexibility. However with rapidly changing systems there no doubt will be problems even with most flexible designs. And this investing thing is like, setting things in stone: "this can change and this not".