Mark Seemann sugere em seu artigo "IQueryable é alto acoplamento" (em inglês) que a criar uma API de tal forma que ela exponha uma interface IQueryable é uma má ideia por várias razões. Mas por quê? Segundo, Seeman:
A interface IQueryable <T> é um dos melhores exemplos de uma Interface de cabeçalho (header interface) que o .NET tem para oferecer. É quase impossível implementá-la por completo.
Isso significa simplesmente que nunca se terá certeza que o método irá retornar uma implementação completa da interface IQueryable.
Implementar a interface IQueryable <T> é uma grande empreitada... basta dar uma olhada na série oficial de posts construindo um provedor IQueryable para entender a dificuldade. E mesmo assim, a interface é tão flexível e expressiva que, com uma única exceção, é possível escrever uma consulta que um provedor não conseguiria traduzir... A única implementação completa da interface IQueryable <T> é a implementação em memória.
De acordo com Seemann, o que torna a abstração fraca é que maioria das vezes a interface IQueryable será implementada por um provedor de armazenamento (store provider) em seu código.
Embora o argumento faça sentido, podemos contra-argumentar: o quanto essa abstração é fraca? Ela ajuda a escrever menos código ou código mais simples? Podemos conviver com as limitações?
Por exemplo, o ASP.NET Web API torna muito mais fácil usar a WebAPI, mesmo para dados filtrados usando parâmetros de requisição web, se o tipo de retorno for um IQueryable. De maneira parecida, há serviços WCF RIA em que os métodos do DomainContext retornando IQueryable poderão ser utilizados pelo cliente para buscar apenas os dados necessários, usando descritores de filtro direto no XAML ou do seu cliente JQuery.
Será, então, que os benefícios da flexibilidade superam a abstração incompleta?