Одна маленькая оптимизация

На самом деле это ожидаемое поведение. Для коллекций свой for, для массивов свой. Ведь возможна ситуация когда на вызов метода iterator() возможна некая логика…

В Java нет структур, которые можно было бы хранить в стеке…

Просто использовать конструкции типа

for (A a : arrayListA) {
// some code
}

не допустимо в серьёзных местах. Лучше просто знать, какой list используется и как лучше его перебирать, а не доверять это for.

Есть предположение, что на производительность процессора и памяти это либо никак не повлияло, либо даже снизило их — если владельцы сервиса на радостях по поводу бесплатной скорости решили перебросить его (сервис) на машинку послабее :)

Вполне нормальная ситуация, если присутствует сложная иерархия. Я специально описал действие метода, чтобы можно было понять откуда это.

В принципе, можно сделать единый итератор по всем трём циклам сразу…

Как-то не очень хорошо обобщать в этой ситуации — «коллекции». Если коллекция не гарантирует доступа по индексу за константное время, то такая «оптимизация» может оказаться не совсем оптимизацией. Речь шла об ArrayList, для него да, ваше замечание интересно.

В общем всё как и должно быть: в релизной сборке разницы нет.

Ну, есть коллекции, доступ к элементам которых по индексу получить нельзя. И если в Ваш метод может прийти одна из таких коллекций на ряду с индексными, то как написать универсальный метод без итератора?

А почему не for each?

Если ваша задача — перебрать элементы std::vector<T> с целью их чтения или модификации — разницы действительно нет (почти, см. примечание). А вот дружить с ними стоит. Потому что:

1. Далеко не для всех коллекций, а вообще говоря, сущностей, содержащих некоторый конечный набор однотипных элементов, эффективен или даже возможен доступ по индексу. В C++ он возможен разве что для std::vector<T> и std::deque<T>, для них же и эффективен (требует константного времени), в Java же и ArrayList<T>, и LinkedList<T>, согласно интерфейсу List<T>, разрешают такой доступ, хотя эффективен он только для первого «списка» (который на самом деле массив ссылок, такой же псевдосписок есть в Qt — QList<T>), для второго требует линейного времени, что простой перебор элементов превращает в алгоритм с квадратичной сложностью. Для таких контейнеров, как множество и отображение (std::map<T>, например), доступ по индексу лишен смысла. Особенно для их unordered_* (в С++11) и Hash* (в Java) версий. И подавно такой доступ бессмысленен для потоков, они предоставляют только итераторы. В C++ STL это будут итераторы категорий InputIterator и OutputIterator (понятие «категория» еще часто именуют как Type Requirements, вещь из мира обобщенного или даже метапрограммирования). Например, std::ostream_iterator<T>. Есть множество потоков, например, в Boost.Spirit вы увидите, что интерфейс, с помощью которого взаимодействуют лексер и парсер — это пара итераторов (в стиле STL, категории ForwardIterator), абстрагирующих доступ к потоку лексем (или токенов). И это очень правильно, потому что резко снижает зависимости между частями системы, например, лексера может и не быть вовсе — а итераторы успешно предоставит, скажем, std::string.

2. Именно концепция итератора позволяет множеству замечательных алгоритмов STL работать с самыми разными коллекциями обобщенным образом. Алгоритмами этими нужно владеть, их надо знать, а это автоматически потребует от вас дружбы с итераторами.

3. Итератор — еще и некоторое обобщение ссылки или указателя на объект. Вы можете его сохранить в каком-нибудь другом объекте. Так вы сможете эффективно удалить или изменить какой-то элемент коллекции, не выполняя поиска. Конечно, тут нужно быть осторожным и знать, какие операции инвалидируют итераторы и ссылки, а какие нет, что индивидуально для каждой коллекции (и отдельная история в многопоточном случае). Практически не актуально для Java, так как удаление элемента даже в «настоящм» связном списке в ее случае инвалидирует все ранее созданные итераторы.

4. Итератор — еще и паттерн проектирования — вы можете использовать его в своих проектах. Тут я не буду останавливаться подробно, а отошлю к GoF.

Обещанное примечание. Разница все же есть, ибо использование итераторов может более менее существенно уменьшить число изменений, которые придется внести в код в случае изменения типа используемой коллекции. Почему такое изменение — не частый сценарий в реальности, можно почитать у Мейерса, «Эффективное использование STL» (как и о многом другом полезном)

Также предлагаю два замечания: о том, как стоит итерироваться по коллекциям в C++11 (не забывайте использовать константную ссылку, если не меняете элементы), и, в качестве примера, C++-way вывода на печать массива пользовательских структур (интересны 35-38 и 46 строчки)

Забыл прокомментировать

Да и [ ] это сложение адресов, а с итераторами — создание объектов.

А что вас заботит? Эффективность? Как показывает, в частности, маленький тест, проведенный мною выше, разницы в производительности в случае С++ нет никакой. В случае Java, как показывает самый этот пост, по-видимому, есть. Но это едва ли, снова таки, должно вас заботить до этапа профилирования, если в нем вообще возникнет необходимость.

в С++ как раз частенько итераторы очень даже нужны
вот вам пример сходу (извините если вдруг, где-нибудь ошибся)

std::vector<int> a;
a.push_back(1);
a.push_back(2);
a.push_back(3);
int b[3] = {4,5,6};
int* c = new int[3];
c[0] = 7;
c[1] = 8;
c[2] = 9;
std::map<int, int> d;
d[1] = 10;
d[2] = 10;
d[3] = 10;
	
print(a.begin(), a.end());
print(&b[0], &b[0] + 3);
print(c, c + 3);
print(d.begin(), d.end());

где

std::ostream& operator << (std::ostream& stream, const std::pair<int, int>& element)
{
    stream << element.first + element.second;
    return stream;
}

template<class T>
void print(const T& begin, const T& end)
{
    for(T current = begin; current!=end;++current)
    {
        std::cout << (*current) << std::endl;
    }
}

И как же ты в Set будешь обрашаться по индексу

А для этого языка, вроде бы, почти всегда достаточно знать, что все, что может объект, можно выяснить исходя из интерфейса. Они документированы и гуглятся хорошо: вот и вот про итераторы. Вот есть же отдельное для списков расширение интерфейса Iterator — ListIterator. Почему нет более развитой иерархии интерфейсов итераторов, среди которых были бы требующие от реализаций методов вроде reset() (из вашего вопроса), мне не известно.