I agree with Joel’s statement that all non-trivial abstractions are leaky in the sense that, by their very nature, abstractions hide details that are considered less important at that particular level. An abstraction has “leaked” the details that it abstracted away.[1]
I disagree, however, with your statement that all abstractions are “failed” abstractions, mostly because you’ve not defined failure. You’ve even provided a pragmatic point-of-view where abstractions are not failures (usability, and ease of understanding).
Basically, if an abstraction hides the details that we are concerned with, then it is our job as developers to choose a different (less abstract) abstraction. If you are concerned with query timing and LINQ doesn’t give you fine-grained control over that, then LINQ is the wrong abstraction to use.
Abstractions only fail when they are wrong tool for the job, but in that case it’s the developer that has failed.
[1] Of course, it is possible to prove that any given abstraction has a one-to-one correlation with what it is abstracting, thus making it a “leakless” abstraction. For instance, one might be able to prove that the SQL grammar is fully covered by the LINQ grammar. But in Joel’s argument, I’ll assume he considers such an abstraction to fall into the “trivial” category.