Large parts of my app work with iterators. There are lists of things and you simply work through them. It doesn’t matter what they are. As usual the example isn’t very good.
I have mailboxes to archive. Could be from a mail client or an imap account. The iterator knows how to pick the next item. The items know what to pick. So the iterators make more sense if you have several different classes implementing the same interface.
Maybe not the best example (sometimes it’s not easy to pick an example with no much code) but it was more about the concepts than the example. I think Iterators are a good solution.
A class might contain an array and additional data which must remain synchronised to the array in some way.
It is not good for objects of this class to expose the array directly through a public method or property, because outside code would then be able to append or remove from the array without the class’s knowledge, possibly putting the object into an inconsistent state.
Using iterators and operator overloading allows the class to provide an array-like interface which is read-only to outside code, but which retains benefits such as compatibility with ‘for each’.