The trouble I have is that when everything has to be completely abstract, and the expert-recommended architecture is to constantly abstract, abstract, and abstract, delegate, delegate, and delegate, down, down, and down into ever-deeper layers of maybe slightly less abstract code, how, and at what point, do you decide where to draw the line and finally bottom out into something concrete? Seems to me it could threaten to become infinitely deep, and even rise that don't usually go too far.
Most code I've seen that the "experts" would consider acceptably abstracted is nearly impossible to comprehend. The abstractions often bear no obvious relation to the ostensible purpose of the code, at least not until you've read-and-understood more layers than I, for one, can keep in my head while waiting to reach bottom and discover what actually happens. And then, by the time I do reach the concrete code, often the higher-level operations have been broken down into such tiny pieces that few, if any, of the concrete methods/functions contain *enough* code to provide sufficient context to tell what *they* do, either.
So in my opinion, extreme OO/abstraction can play hell with readability, this understanding, and thus using, these code architectures that experts praise. What good is beautiful code, if the would-be user's reaction is "screw it, I'll write my own?" Your priorities seem misplaced.