IQueryable vs Specification + Repository

Question

.NET

Hello. There is a common-sense opinion that IQueryable doesn't violate LSP so badly: blog.ploeh.dk/2012/03/26/IQueryableTisTightCoupling/ . Indeed, the only linq provider that will "digest" any condition is an in-memory implementation, which contradicts the very meaning of the interface as a translator.
At the same time, I like Repository and Specification even less: blog.byndyu.ru/2011/08/repository.html .

And everything would be fine in QueryObject if I didn't consider that

public class FindAccountByEmailQuery
{
    private readonly ILinqProvider linqProvider;
    private string email;
 
    public FindAccountByEmailQuery(ILinqProvider linqProvider, string email)
    {
        this.linqProvider = linqProvider;
        this.email = email;
    }
 
    public Account Execute()
    {
        return linq.Query()
            .Where(x => x.Email == email)
            .SingleOrDefault();
    }
}

a lot of letters for something as simple as

            .Where(x => x.Email == email)
            .SingleOrDefault();

On one project I tried this approach: where you need to get objects on request: linq sticks out. The GetById method naturally stands apart due to its frequent use. As long as linq queries are testable and small, we do nothing. As soon as there are hellish requests or I use the construction more than twice or it is impossible to write the tested linq (constructs like SqlFunctions etc are used), a separate method is automatically allocated.

If there are too many methods to get values ​​by the criterion (given that linq sticks out, this rarely happens), the methods go to a separate Repository.

In this case, there is a deliberate violation of SRP: a domain object can contain both methods for obtaining a value by a criterion and other operations. I go for it because each domain object, however, only works with its own entity. Here, I'd rather have fewer classes and simpler code than make everything "kosher".

What I get out of it: little infrastructure code, testability, strong coupling of components at the linq level, which does not really bother me.

Of the minuses, I see that it may not be obvious to all developers in the project when linq should be refactored and when to introduce a new object for queries. In fact, there are formal criteria, but they are more complicated than if you just say: “always make a repository for requests, then a service, etc.”

Are there any other downsides to this "hybrid" approach that I don't see?