Separate domain models and entities used in EF Core?

Im unsure on wether I should let EF use my domain models or not.

Right now I have three types of models:

• Core.Models (System wide)
• API.Models (Used only in controllers)
• Infrastructure.Entities (Only used for persistence)

Every method in my service classes look like this:

1. Get entity from DB
2. Change properties on entity based on request
3. Save changes

This works great when using the domain entities, as EF starts tracking the changes and can persist only what's been changed.

If I instead map to domain models when retrieving from the DB, so that my services only work on domain models, my changes aren't tracked of course:

1. Get entity from DB, as untracked, and map to domain model
2. Change properties on domain model based on request
3. Map back to entity
4. Do complex graph diff (set state manually on what has been changed since changes aren't tracked)
5. Save changes

The entities contain no data annotations or nothing, I'm using the Fluent API. I see no point in separating domain models and entities. I'm looking at examples from Jimmy Bogard, Steve 'Ardalis' Smith, Jason Taylor, and they are all using their domain models as their EF entities. Are they doing that to keep the code simple for demo purposes or is not beneficial to separate models and entities?