На самом деле вопрос сложнее чем кажется. Понятно, что если задается какая-то константная коллекция, то лучше определить ее массивом, а не списком. Однако, есть мнение, что массивы можно (и даже нужно) использовать более активно, в частности, возвращать из различных сервисов и репозиториев.

Например, рассмотрим два варианта одного и того же репозитория. Со списком:

// Вариант A
public interface ICustomerRepository {
    IList<Customer> GetAll();
}

С массивом:

// Вариант B
public interface ICustomerRepository {
    Customer[] GetAll();
}

Для варианта со списком имеем следующие преимущества:

• возвращается объект, реализующий интерфейс (IList<>), а не экземпляр конкретного класса. Значит кокретный репозиторий может вернуть специфическую реализацию списка. Так, NHibernate может вернуть коллекцию с возможностью загрузки по требованию и тд.
• Возвращается объект, удобный для клиента — списки легко сортировать, фильтровать и тд.

Но есть один недостаток, связанный с парадигмой императивного программирования — возвращаемый список является изменяемым (mutable), клиент легко может добавить/удалить элементы в списке. Но что произойдет если клиент скажем добавит элемент в список:

var allCustomers = CustomerRepository.GetAll();
allCustomers.Add(new Customer());

Добавится ли при этом объект new Customer() в репозиторий? Изменится ли при этом внутреннее состояние самого репозитория? Интерфейс (A) не дает ответы на эти вопросы.

Преимущества варианта с массивом:

• Возвращается легковесный и наиболее простой объект;
• Вариант работает даже в доисторических версиях .NET;
• Возвращается относительно неизменяемый объект (immutable). Клиент все еще может изменить элементы массива, но его длинна остается постоянной. Это конечно не решение проблемы, но все же массив считается «более неизменяемым» чем список. То есть интерфейс (B) лучше отображает сущность метода GetAll — вернуть список объектов для чтения.