Thanks JB for this write-up. I totally agree with what you are saying, and I second your idea that everyone should try doing this.
Going to your question "how do you explain DIP to others", I usually explained brifly this concept during trainings and coderetreats, but never at large. I like to tell people that I arrive through refactoring at a graph of objects that communicate with each other. The main advantage is for me that I end up at the core OOP pattern "messages and dispatch", I just have abstractions sending messages when needed. I also explain that these abstractions are easier to be transformed into entities respecting the principles "low coupling & high cohesion". The less I need to couple the abstractions, the happier I am.
Also, especially working on old code bases, when I refactor I end up with a code that is more efficient, because a lot of the logical branches disappear. All the control is moved at the entry point, and only the needed abstractions are used, not more and not less.
What are your thoughts on that?