Thanks Olivier for spending the time going through this and your relevant comments. I agree the term RideRepository is a bit confusing here: Repository in DDD lingo is indeed a concept generally understood as the intermediary between the domain model layers and data mapping & persistence.
In the context of this article and event sourcing, responsibilities of domain services (business logic) and persistence are kind of “collapsed” into one because we are not describing data operations in terms of CRUD, but in the form of domain events that get persisted. In some sense, even the persisted form of the entity has “business” meaning, as it represents a sequence of events relevant to the domain (RideStarted, RideCompleted e.g.).
Our repository is thus closer to the concept of domain service as you say: under a DDD lens, RideService is probably a more suitable name as you suggest.