The question (and title) is steeped in a general conflation of different concepts such as DDD, CQRS and the repository pattern, and implied statements that they are mutually exclusive or that they are different solutions to the same problem.
None of that is the case. These three concepts all act on a different scope, and can be implemented (or not) without that therefore requiring/excluding the implementation of the others.
Command handlers should be in the application service layer, correct?
There's nothing in the definition of CQRS that dictates that this is an application layer implementation. CQRS dictates that you split your logic across individual handlers (as opposed to e.g. bundling them in a single service interface).
However, one can implement this kind of separation in any layer they want to. This could be implemented on the Application layer (and to be fair it commonly is), but it could just as well be implemented on the Persistence layer.
There's no conclusive answer here, other than "no, it's not inherently about the Application layer".
I don't understand how can using CQRS mean we don't need repositories anymore.
Generally speaking (observe that I'm going to address fringe definitions in a moment), repositories are thought of as the same kind of service interface that bundles all of the interactions (commands, queries) related to a particular data store (commonly scopes to a particular database table), just like I described before. Using this interpretation, one could inherently imply that repositories are at odds with CQRS in the sense that repositories bundle the operations whereas CQRS inherently prescribes their separation.
However, there is wiggle room in all of these definition and interpretations.
For example, one could separate their classic repository into a read repository and a write repository. The queries are then not individually separate (neither are the commands), but the queries are separated from the commands and this sufficiently satisfies the definition of CQRS.
Another thing to point out might be that the CQRS separation might only be enforced on the interface level, i.e. the application talks to the persistence layer using individually decouples query/command objects/interfaces. But in the actual implementation of the persistence layer, there might still be a single repository that implements multiple of these interfaces/handlers.
This can make sense in cases where you want to have some reusability (I'm thinking of e.g. a reusable repository mock for testing purposes), or if you want your overall codebase to already be CQRS-compatible even though you haven't actually separated your read and write stores themselves just yet. Not a common scenario but one I have concretely encountered.
You'll notice that I haven't yet brought up DDD, and there's no reason to do so. DDD is completely unrelated to this alleged conflict between CQRS and repositories. Sure, in a DDD context your specific syntax is going to look a bit different, but its inclusion (or lack thereof) doesn't impact the general considerations that this answer touched on.
The main point here is that depending on your specific definition of CQRS and repositories, they could be interpreted as being polar opposites or not. So you could be right, as could the person who you are quoting and seemingly disagreeing with.