The most generic answer is to leverage a profiler; and you generally don't want to worry about these sorts of decisions too much until you have evidence that they are the source of an actual performance issue in your game.
However, you can make some initial decisions about the choice of container and traversal method based on some information about the algorithmic properties of those containers. For example, if all you're going is traversing a collection in order over and over, an array is usually better than a linked list due to its improved cache coherency / locality of reference (arrays are contiguous; elements in a linked list may be spread out all over your address space unless you're using a pooling allocator for the elements).
Similarly, trivial iteration of an array via a for loop with an index is about as bare as you can get: it involves the minimum of overhead. Iterators usually require the construction of some object and related state (because they hold the iteration state within them). This means they have a very slight memory overhead and potential garbage-collection overhead (due to transient object allocation). But on balance, they allow you to pass the iteration state around to other interfaces -- generally provided that you don't modify the underlying container during the iteration, which can invalidate the object state.
In short, to best decide the data structure you need, and the interaction methods you should use with that structure, you should make sure you have a basic understanding of the algorithmic tradeoffs of your options and the context within your game where you're going to employ these structures. Beyond that, you should not stress out about it too much -- always aim for readable, clear code first. Then profile your game regularly and investigate actual bottlenecks as they arise.