What is the benefit of doing this?
One thing to keep in mind is that the application, the domain model, and persistence each evolve at a different pace from the others. The domain is expected to be able to support multiple applications; and you are supposed to be able to revise the implementation within the domain frequently -- but persistence generally evolves more slowly, because we don't throw away the accumulated state each time we update the model.
The Repository interfaces were contained in the Core project and the Repository classes (implementations) were contained in the Infrastructure project.
Well, the repository interface is the contract that defines the agreement between the application and the domain model (which is itself encapsulating the persistence component behind it). So it makes a certain amount of sense that those interfaces are either in core or in application -- if you aren't going to pull them out separately, and you are expecting to support multiple applications, core is the natural home for them.
As for where the implementations go, that gets a bit trickier. The entities and values in your domain model have two logically distinct representations - the one you see in memory, and the one you see in your durable store (think objects in memory vs rows in an RDBMS).
What Evans described in the blue book is that the role of the repository is to provide the illusion that the aggregates all live in memory. So it's reasonable to think of the repository as a service provider interface, with the infrastructure component as the service provider responsible for deciding how to serialize/deserialize data to/from the book of record.
CQRS helps to make this separation clear; because the read and write use cases differ, the roles defined for the repository are also different. In particular, it's not surprising that we might decide that a particular use case wants a specific kind of data store -- a document store for providing cached representations of views, or a graph database for fast queries of a social network.
In this sort of a design, that change is easy -- you just swap out the specific persistence implementation, and the changes to the applications and the domain models are minimal; the infrastructure changes a lot (complete replacement within that use case), and the composition root a little (replacing one persistence module with another), but the model and the application are unaffected by the change.
It can, of course, get more intricate: in event sourced systems, you normally have a representation of events in your durable event store, which may or may not align with the representation of events in memory, which in turn are distinct from the representations of the aggregates that you use when computing new events. In this sort of system, the persistence component would normally be concerned with writing events to and from your event store, where the translations of event histories to and from the aggregates would live in the domain model (ie: core).