foreach or for that is the question

Давно уже нет никакого вопроса о выборе между одним и другим: какая семантика вам нужна, тем и пользуйтесь. Учитывая, что в значимой части случаев в реальной жизни вы имеете дело не с массивами и списками, а с enumerable, вопроса и вовсе не стоит.

Ваше объяснение результатов вряд ли верно в обоих случаях, потому что еденицы наносекунд на итерацию, тем более, разница всего в 1,5 нс в первом тесте, которую вы объяснили вызовом делегата, — это не то время, за которые происходит вызов.

Скорее всего, там инлайн полный во всех случаях, разница в паре проверок границ лишних, может быть.

Кстати, 2,5 нс на итерацию суммы простого массива в цикле — как-то медленно.

Мне кажется, что на несинтетических примерах замена for на foreach вообще заметной разницы в скорости не даст. А вот время разбирающихся в коде людей, если увлечься такой оптимизацией, можно и потерять.

C# For vs. Foreach — для массивов foreach может оказаться быстрее, чем for, если требуется несколько раз обращаться к элементу по индексу.
Согласен с комментариями выше — задумываться над выбором for/foreach не должно требоваться — компилятор должен оптимизировать — это его работа. Однако, знать что «под капотом» у обеих конструкций стоит, но не помешала бы статья про оптимизации циклов в .NET, дабы стало в очередной раз ясно, что преждевременная оптимизация — корень зла.

Обычно стараюсь использовать foreach или .ForEach для краткости и чистоты кода. За исключением случаев, когда в цикле нужно менять элементы коллекции, тогда без for не обойдёшься. Пусть производительность и разная, но в большинстве случаев это не критично. PS: игроделы, не читайте последнее предложение :)

А вы уверены в правильности составленного бенчмарка?
Я сделал свою версию замеров производительности в рамках проекта BenchmarkDotNet: примеры ForeachArray и ForeachList. Мои результаты несколько отличаются от ваших (количество итераций — 200000000):

ArrayForWithoutOptimization : 143ms
ArrayForWithOptimization    : 143ms
ArrayForeach                : 142ms
ArrayForEach                : 556ms

ListForWithoutOptimization  : 280ms
ListForWithOptimization     : 213ms
ListForeach                 : 628ms
ListForEach                 : 833ms

По массивам вопросов нет, а вот о производительности итерирования по List-ам я готов подискутировать. Я считаю, что обычный for работает быстрее, как этого и следовало ожидать.

Оверхед на циклах это абсолютная мелочь. Из критичных по производительности вещей с циклами гораздо чаще встречается неправильный выбор коллекций для работы (игнор существования HashSet или Dictionary там, где необходим поиск по значению элемента).

Могу подкинуть еще одну интересную тему, если хочется покопаться в .NET. Есть такой класс — Dictionaty<TKey, TValue>, для выяснения равенства значений там используется IEqualityComparer. Если почитать исходники, то можно увидеть, что если вызвать конструктор словаря без компарера в качестве параметра, то в качестве компарера будет использован EqualityComparer<TKey>.Default.
А он реализован так:

[Serializable]
internal class GenericEqualityComparer<t>: EqualityComparer<t> where T: IEquatable<t>
{
     [Pure]
     public override bool Equals(T x, T y) {
        if (x != null) {
            if (y != null) return x.Equals(y);
            return false;
        }
        if (y != null) return false;
        return true;
    }
}

Т.е. по логике вещей, что бы сравнить 2 целых числа, каждое из чисел нужно преобразовать в ссылку на интерфейс IEquatable<int>, а интерфейс как известно — reference-тип, что бы вызвать метод Equals нужно упаковать объект. И вот тут я немного не догоняю, выходит, что CLR либо умеет вызывать методы объектов value-типов не упаковывая их, что не вяжется с понятием интерфейса, либо поиск в словаре с компарером по умолчанию производит упаковку элементов, а значит приличное количество мусора при интенсивном поиске, о чем нам как-бы говорит сравнение параметров с null! Если порыться профилировщиком, то вроде бы этого не происходит. Интересно, для этого там введены специальные хаки — EnumComparer и ByteComparer?

Статье явно не хватает сравнения и анализа генерируемого IL кода.

Стоило также протестировать скорость выполнения linq-функций: Sum и Aggregate, раз уж для тестов была выбрана задача суммирования последовательности

Заодно советую автору изучить эту статью, тем более, что она вышла всего неделю назад:
habrahabr.ru/post/191636/