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.