Это довольно неясно, но я думаю, что это оптимизация. Это как-то связано с тем, как реализованы дженерики. Машинный код для универсального метода класса создается во время выполнения компилятором JIT. Нужно сделать несколько конкретных версий этого. Существует один для любого ссылочного типа. И по одному для каждого аргумента типа значения, используемого в программе.
Это может быть неэффективно, потенциально много кода, который необходимо сгенерировать. Особенно плохо для базовых классов фреймворков, они Ngen-ed. Конкретная реализация метода должна быть скомпилирована JIT и не может быть в образе Ngen.
Для борьбы с этим в фреймворке есть частный код (извините, я забыл, где), который создает целый набор различных версий универсальных классов. Интересный код "ничего не делать", он довольно долго меня озадачивал. Но побочным эффектом является то, что Ngen.exe генерирует код для универсальных методов класса. Если вы теперь используете такой универсальный класс в своем собственном коде, вы получите конкретную реализацию метода из образа Ngen, компилятор JIT не нужен.
Вы можете видеть, к чему это ведет, System.Collections.ObjectModel.ReadOnlyCollection, вероятно, считался слишком неясным для включения в этот список. Легко проверяемый, вы увидите, что если вы перейдете к одному из его методов, вы не войдете в исходный код, даже если у вас есть Reference Source .pdbs.
Я не уверен на 100%, что это точное объяснение. Но обувь подходит.