Какие плюсы и минусы у List в C#?

Ну ты представляешь, этот List<T> — он как наш классический семейный седан. Вроде бы ничего особенного, но в 90% случаев именно он тебя и вывозит, потому что сбалансирован по всем параметрам. А всё почему? Да потому что внутри у него, по сути, обычный массив T[] сидит, вот и весь секрет.

Чем он хорош, этот ваш лист:

1. Доступ по индексу — просто космос. Хочешь 5-й элемент, хочешь 500-й — пишешь list[499] и получаешь его моментально, за O(1). Потому что под капотом массив, а к массиву по индексу обращаться — это как в свой холодильник ночью на кухню сходить, ты уже наизусть знаешь, где что лежит.
2. Растёт как на дрожжах. Не надо заранее голову ломать, сколько там элементов будет. Создал пустой, а он сам себе место под новые элементы подготавливает. Внутренняя ёмкость (Capacity) увеличивается, когда надо. Удобно, чё.
3. Методов — как грязи. .Add(), .Remove(), .Find(), .Sort() — всё под рукой. И с LINQ он дружит на ура, можно фильтровать, преобразовывать, агрегировать — красота.
4. Дружит с кэшем процессора. Элементы-то в памяти друг за дружкой лежат, рядком. Когда ты по списку в цикле пробегаешься, процессор это предсказывает и заранее данные в кэш тащит. Поэтому итерация — одна из самых быстрых операций для него.
5. Памяти жрёт относительно немного. По сравнению с какими-нибудь связными списками (LinkedList<T>), где на каждый элемент ещё и ссылки вперед-назад хранить надо, тут overhead минимальный. Просто массив да парочка служебных полей.

А теперь, блядь, ложка дёгтя. Минусы-то какие:

1. Вставка или удаление в середину — это пиздец. Ну представь: у тебя список из 1000 элементов, и ты в самое начало новый элемент пихнуть решил. Ему же надо всем остальным 999 элементам в памяти место уступить, их всех на один шаг вправо подвинуть! Сложность O(n), и чем список больше, тем больнее. Удаление из середины — та же история, только сдвиг влево.
2. Переезд с вещами. Когда внутренний массив заполняется, листу приходится устраивать переезд: найти новый, больший участок памяти (обычно в 2 раза больше), туда все свои пожитки скопировать, а старый выкинуть. Операция не мгновенная, на больших списках может вызвать просадку по перфомансу.
3. Может память зря транжирить. Если ты заранее зарезервировал место (Capacity) на 10000 элементов, а используешь только 10, то память-то под все 10000 выделена и простаивает. Можно, конечно, TrimExcess() позвать, чтоб подогнать размер, но это надо не забыть.
4. Для очередей или стеков — не самый лучший выбор. Если тебе постоянно нужно добавлять/удалять элементы только в начале или только в конце, то Queue<T> или Stack<T> будут шустрее. А LinkedList<T> вообще для частых вставок/удалений в любом месте создан.

Короче, смотри на жизнь практично:

// Вот тут List<T> — просто царь и бог. Часто добавляем в конец и читаем по индексу.
var scores = new List<int>(1000); // Сразу заказываем место, чтоб не переезжать
for (int i = 0; i < 1000; i++) scores.Add(i * 10); // Добавляем в конец — быстро и без боли
var topScore = scores[999]; // Берём по индексу — мгновенно!

// А вот тут он уже выглядит как слон в посудной лавке. Частые вставки в начало.
var logEntries = new List<string>();
// Каждая новая запись в начало будет сдвигать ВСЕ предыдущие. Это пиздец как медленно!
logEntries.Insert(0, "New log entry"); // O(n) — чем список длиннее, тем хуже.

// Для такой задачи возьми лучше LinkedList<T>.
var betterLog = new LinkedList<string>();
betterLog.AddFirst("New log entry"); // O(1) — и хоть миллион записей будет, скорость та же.

Итог, ёпта: List<T> — это твой универсальный солдат. Для большинства повседневных задач — идеален. Но если в твоём алгоритме сплошная карусель из вставок и удалений где-то посередине коллекции — ищи другие инструменты, не мучай ни себя, ни список.