While I place importance in the performance of any piece of code, I must admit that one of the driving forces in using heavily abstracted technologies -- that by their very nature add heaps of overhead -- is the client.
Clients are less interested in how properly coded their product is than the time-to-production.
I just went through an application that was using a vanilla datagrid to display a a paged result set, but the paging was being done client side and as a result a quarter hundred thousand records were being pulled from the database each page, while onlyl a hundred or so were being displayed.
My guess is that the original developer had not thought how many records there were going to be, instead focusing on the business logic around the abstracting control (the datagrid).
This abstraction was causing intermittent problems with resource usage (although I have not explicitly proved this, I think it is most likely), it had finally leaked.
Now this abstraction may have saved a few hours of coding but in the end it caused more hours of support work, and some user dissatisfaction.
It's not always clear when your abstraction will bite you in the @$$ at the end of the day, but it is important to know the pitfalls your abstraction will have, and when they may occur.