Conclusion:

If you use only simple stuff with EF and not predict to have any complex queries, especially such that "leak" DB like .Include and low level DB stuff, it's fine to use EF6 as a repository, even though it's a bit harder to unit test againt it (when it's a dependency) it still CAN be unit tested (a bit more combursome than repository) with the new IDbContext of EF6. So use EF inside your serivce layer.

If you expect it to be a big DB and project and many unit tests it might be worth it to introduce a repository, because after all tests will be simpler that way. Also that way the service layer won't have the "leaky abstraction" of EF which is too "low-level" comparing to a repository.

I feel that for a "big" project I'd still use a repository, it'd hide fat linq queries from my service layer and make the unit tests much simpler. After all "The repository pattern is an abstraction. It's purpose is to reduce complexity and make the rest of the code persistant ignorant. As a bonus it allows you to write unit tests instead of integration tests."

Sources:

https://stackoverflow.com/questions/35322956/why-should-i-build-a-repository-pattern-with-a-unit-of-work-on-the-top-of-my-ef

https://softwareengineering.stackexchange.com/questions/180851/why-shouldnt-i-use-the-repository-pattern-with-entity-framework

https://stackoverflow.com/a/17449231/1057791

https://softwareengineering.stackexchange.com/questions/314266/are-repositories-needed-any-longer-in-asp-net-5-ef7