nozd up

Значит так, берем толстую тетрадь, ручку и пишем фразу "Статические методы не имеют отношения к ООП" до тех пор, пока не запомним это на всю жизнь.
Суть объектно ориентированного программирование, как понятно из названия, заключается в том, что должен существовать объект. Статика существует не в контексте объекта, а в контексте класса! Из этого вытекает то, что на протяжении всего жизненного цикла вашего кода будет существовать лишь одно глобальное состояние статических членов класса.

Использовать статику нужно в случае, если то, что вы ей описываете принадлежит всей группе объектов, а не одному. Например, у класса Human может быть статический метод numberOfLegs(), который возвращает количество ног у людей. Количество ног - это общее свойство для всех людей (Речь идет о здоровых людях). В данном случае можно было использовать константу класса, но это не так важно, ведь, по сути, константа - это тоже статический контекст. А вот имя - это уже свойство каждого отдельного человека. И очень важно чтобы статические методы не изменяли состояние системы в целом, не содержали побочных эффектов.
В статические методы можно выносить какую либо служебную логику. Например, метод перевода числа из арабской в римскую запись следует сделать статическим.

Есть ли у статического варианта какие-то подводные камни

Большое количество. При чем, не таких уж и подводных. Из-за того, что статика глобальна, она плохо поддается тестированию, ее нельзя замокать. Глобальное состояние плохо поддается отладке. Отсутствует возможность подменить реализацию, так как это позволяют сделать объекты.

1. Ну, `List` не потокобезопасен. Для избежания Kernel-mode constructs (`lock` и пр.) можно попробовать потокобезопасные ConcurrentQueue или ConcurrentStack в System.Collections.Concurrent, если заполнение до чтения (а не вовремя). Наполняете, вызываете GetEnumerable, который делает снэпшот коллекции, сравниваете. Чтение должно происходить без блокировки.

2. BlockingCollection для проблемы producer-consumer, когда одновременно чтение и запись. Я так понял это не входит в задачу.

3. Если вы не изменяете, то и блокировать не нужно. Вне зависимости от reference или value type. (Конечно, через стэк лучше, если изменяете. Тогда копия для каждого потока своя.)

По теме можно Рихтера почитать, CLR via C#, 10 глава, Asynchronous Synchronization и The Concurrent Collection Classes

Читать стоит классику жанра:
Э.Фримен, Э. Фримен — Паттерны проектирования
Э.Гамма, Р.Хелм, Р.Джонсон, Дж.Влиссидес. — Приемы объектно-ориентированного проектирования. Паттерны проектирования
М.Фаулер - шаблоны корпоративных приложений

Лучше конечно читать в оригинале, но есть и переводы на русском