Принятого не воротай: Enumerable vs List

IReadOnlyList: IReadOnlyCollection — неизменяемая коллекция с порядком следования элементов, вам доступен индексатор

Строго говоря любой IEnumerable определяет порядок следования, тут просто есть доступ по индексу элемента. Причём никто не мешает сделать реализацию, где индексы будут расставлены случайно (зачем — отдельный вопрос)

Что касается рекомендаций к ознакомлению, то можно ознакомится со всей книгой Цвалины Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries. Второе издание есть на русском, но в этом году вышло третье издание с асинхронностью и прочими плюшками. Крайне интересно читать, тем более, что прямо в книге разворачиваются холивары по некоторым вопросам.

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

1. Массив это объект и подвержен сборке мусора. И если мы возвращаем его из функции, то он сразу попадет в GC Gen 1. А в плохом раскладе и в Gen 2. Массовый ToArray() по всему коду может удвоить нагрузку на GC, что не критично для небольшого проекта, но может быть важно в бекэнде. Чтобы бороться с этим в .Net Core сделан ArrayPool<>, но с ним есть нюанс №2.
2. Получив из ArrayPool<> массив нельзя быть уверенным, что его длина не больше, чем надо и что вы заполните все его элементы. В итоге некоторые программисты начинают возвращать из каждого метода ArraySegment, собственную обертку, отдельно значение count. Либо таки возвращают массив и каждый элемент при переборе сравнивают с null или default. Отдельно остается вопрос, что массивы надо бы и возвращать в пул, а за этим автор метода уже проследить не может.
3. Массив структур физически хранит в себе эти структуры и его создание через ToArray() или CopyTo приведет к массовому копированию. Ну а сам массив потенциально может попасть в LOH, для этого достаточно иметь всего 85000 байт размера. Обработка LOH объектов обычно блокирующая, т.е. останавливает ваше приложение. Есть исключения, но речь не о них.
4. В отличие от IReadOnlyList<>, в массиве можно заменить элемент с каким-то индексом и изначальный метод не узнает об этом.

Моя рекомендация: возвращайте из методов IEnumerable, IReadOnlyCollection, IReadOnlyList (если нужен доступ по индексу). Не заморачивайтесь с массивами, если это не требуется явно. И точно не делайте ToArray по поводу и без повода, от этого код не станет работать быстрее.

Информировать пользователя о том, используется ли lazy loading, посредством возвращаемого типа — плохая идея. Вы обременяете тип несвойственными ему обязанностями.

А вот не факт что они ему несвойственны, использование типов для изоляции поведения — это очень популярный паттерн в ФП, да и в DDD занимаются чем-то похожим.

Другое дело, что IEnumerable<> для этих целей не подходит.

Возвращать Array или IReadOnlyCollection вместо List, смысл есть только когда вам важно подчеркнуть неизменяемость. Во всех остальных случаях IList предложит более широкую функциональность примерно за ту же стоимость.

Только помните, что подчеркивание неизменяемости является очень даже полезной привычкой.

Вообще-то, Enumerable это ни в коем случае не лист и не коллекция; ставить меж ними знак равенства — верная дорога к интересным багам
Например,

IEnumerable<int> getEnumerable()
        {
            for (var rand = new Random();;)
            {
                yield return rand.Next();
            }
        }

Попробуйте вызвать getEnumerable().ToList() :))