I understand how you feel. I'm not suggesting that everything become perfectly abstract, but I am trying to describe the benefits of making more things more abstract, because 99.9% of the designs I see out there suffer from being overly-fixated on details (too concrete), leading to duplication, copy/paste mistakes, latent bugs, unhealthy interdependencies... all diseases of too many details. Like it or not, abstraction is how we hide details and how we go from low-level understanding to high-level understanding.
Abstractions without appropriate names cause problems, so we need to take names seriously, which is why I have a system for doing just that. http://link.jbrains.ca/ovMMvz and http://link.jbrains.ca/UXOYK6
Indirection without abstraction, also knows as leaky abstraction, causes cohesion problems that directly relate to your well-founded concerns. We need to learn that abstraction is not just indirection. Details move up the call stack and patterns of behavior move down. That's why I wrote about this problem in http://link.jbrains.ca/1cIWL4u and less obviously in http://link.jbrains.ca/119E8jy
When abstractions leak, we end up with implicit dependencies: we think we've hidden details, but we haven't. I see this especially in poorly-designed attempts at introducing class hierarchies, especially especially in little mini-frameworks. That's why I wrote about my pain in trying to add code to Octopress 2. http://link.jbrains.ca/GZYYhA
I hope some of this helps.