Not saying we should always invoke SaveChanges, but doing brings a lot of advantages while prevent a lot of bugs.

First, and starting by your example, every repository should provide bulk CUD operations. This means if I want to, for example, create a bunch of new entities, I can do so in an optimized way doing a single SaveChanges at the end.

Secondly, it ensures that if a complex operation needs to, let's say, aggregate some data based on existing entities while including changes that were made inside that business transaction, always invoking SaveChanges ensure all data will be considered by the database. Remember that not every operation is a simple read by ID, making it impossible for EF to use it's first level cache.

Thirdly, if your architecture ensures transactions are automatically created when executing some business operation (either via Aspects, Decorators, wtv) and if your repositories automatically execute SaveChanges, there will be zero bugs regarding ACID properties. You'll be able to sleep well knowing no developer will forget to send changes to the database and if an exception occurs everything will be reverted. I wrote some articles how you could easily implemented this using the mediator pattern.

Lastly, imagine you are using some SQL database and for some reason you have to execute raw SQL code (for example, an optimized select) but you don't want to implement the all operation in raw SQL, this will make it possible.

In summary, having your repositories always calling SaveChanges is not a requirement, but unless you are creating and application with simple CRUD operations were first level cache is really helpful, it sure provides more advantages than disadvantages.