But my doubt is, if the domain model only has to do the business logic, why does it has to load the data from the database and persists the updates in the database?
It doesn't load the data, nor does it persist the updates. It tells someone else (i.e. the repository) to load the data and to persist the updates.
Don't confusing doing a job with instructing someone else to do a job, because these are very different when you are considering a class' responsibilities.
At the end of the day, it is the repository which decides how to load data and how to persist it. The only thing the domain does (other than the business logic) is connect itself to the repository.
I guess it is more flexible to have a domain to only do the work of the domain and let to another the responsability to persist the data.
Not to belabor the point, but that is precisely what is already happening in your original example. The repository is already the one tasked with the retrieval and storage logic.
So a consumer (the UI or user) can decide when persist the data, using the service or only want to do a work in the instance of a domain that it has locally.
Keep in mind that you're asking a question about domain-driven design. It is the domain who calls the shots here. It doesn't do the legwork (that's what the repository is for), but it does make the final call on whether the repository gets instructed to do something or not.
I guess it is more flexible to have a domain to only do the work of the domain and let to another the responsability to persist the data.
If you do this, then you effectively demote the domain. It is now no longer the big boss calling the shots, because "another" is now telling the domain to execute a specific job, rather than let the domain define the job that needs to be done.
The core of DDD is that the Domain is the big boss of the logic, and the other layers exist mostly to shoulder the burden of minor tasks (such as persistence or mapping), so that the Domain can focus solely on the business logic itself. It's about delegation: the domain calls the play and the surrounding layers execute it. This ensures that the domain logic remains as simple, readable and change-friendly as possible.
The inability to easily adapt or adjust the core bsuiness logic is a very common cause for software applications to hit a very difficult, slow and/or expensive maintenance phase. DDD tries to avoid this as best as possible by keeping the domain logic light and undistracted by technical implementation details such as which DB server to connect to or how to map to DTOs.