Architecture :: Repository Pattern - Pros And Cons?

This is possibly the worst kind of religious debate -- a religious debate with practical consequences. But it's one that needs to be had, and I can't seem to fit it in my tiny head. Here are the pros and cons of the pattern as I know them:

Pros:

-Encourages DRY (don't repeat yourself) design in that identical queries are written only once per set of query conditions
-Facilitates unit testing by allowing itself to be abstracted into an interface
-Creates an opportunity for business-level validation

Cons:

-Breaks DRY philosophy in that you're generally repeating your database schema
-In a sense breaks separation of concerns, because the query concerns of the controller and view frequently become the concerns of whoever is maintaining the repository
-Determining what should be a repository and what should be returned as a raw associated ORM entity becomes an ambiguous art

To me it seems like all this stuff should be done at the ORM level, but Entity Framework has much fewer hooks than Linq to Sql does, yet Entity Framework tends to be regarded as being more robust, so it seems that this is by design, and that the designers of EF are in fact encouraging another layer. Are there any tools or anything that I could be using for this? Am I missing something?