I agree in part, but I think this is too narrow a view of what "performance" means or should mean. In my opinion, performance is multi-dimensional and it can only be defined from the point of view of the user/customer/business. That is where focus is critical.

Reponsiveness is merely one kind of performance measure. Another measure might be agility or adaptability (e.g. the turnaround time for necessary changes to the codebase to be rolled into production). This matters for things like new product development where new products have large impacts on existing systems and processes and time-to-market is critical for competitiveness.

From that perspective, if agility is one of the performance metric, then abstraction may be a useful tool at incresing agility, despite a cost in responsiveness. Or at least, improvements in agility must be traded off against costs in decreased responsiveness. Other metrics might include ongoing maintenance costs, which again might mean a different tradeoff between speed of execution and abstraction.

People shouldn't get so caught up searching for a nail for their hammer, whether that's "efficiency" or "abstraction". There is no one universal tool -- it takes a whole toolbox, properly applied to the task at hand, to deliver a valuable solution.