[Tails]

Данный класс будет слишком раздутым, так что в нём будет тяжело ориентироваться

Количество строк кода не так страшно, как его запутанность. Даже если в классе будет более 2к строк, это не проблема, в любой нормальной иде есть "сворачивалки кода", закладки, различные способы навигаций и т.д. Главное, что-бы один класс выполнял строго одну задачу, тогда всё будет по красоте. Когда класс решает более одной задачи, тогда можно и в 200 строчках намутить такого, что чёрт ноги сломит. В данном случае, это просто справочник и в нём не будет много строчек, он будет иметь только список переменных.

Объём загружаемой и хранимой инфо будет слишком большим с т.з. ресурсов системы

Я думаю, напротив, это - самый минималистичный способ представления данных. Только чистые данные, без чего либо лишнего. Как уже писал выше, для сравнения:
Мой гоблин в рантайме:
id, unitID, life - Не более 16 байт. (4 + 4 + 8)

Гоблин по принципу - "объект сам себе режисёр":
Содержит текущие данные, копию его статичных данных (Имя юнита, например) и данные всей цепочки наследования + EventDispatcher. Потребление памяти будет явно в несколько раз больше.

Над различными аспектами игры трудятся разные люди в команде, поэтому им удобнее иметь свои справочники, а не делить один общий.

Наврядли приветствуется такой подход. Скорее, в командах есть главный архитектор, который раздаёт всем остальным реализацию составленного им дизайна апи того или иного модуля программы. То-есть, формат у всех единый. В моём опыте я пересекался с другими программистами только в способах коммуникаций и передачи данных. (Я писал клиент, другой человек - сервер и т.п.)

И если у тебя все справочники живут вместе, зачем тебе наследовать классы парсеров?

Конкретно тут, наверное, незачем. Я это сказал к тому, что обычный объект класса предпочтительнее статического, по некоторым важным причинам. Давно ещё где-то читал, из аргументов помню: Невозможность наследования, переопределения, имплементации интерфейса и ещё вроде что-то было. Поэтому, если в этом особой нужды нету, то не нужно так делать.

Я правильно понимаю, что парсер - это у тебя такая огромная простыня с кол-вом методов по кол-ву классов-листов?

У меня да. Вы можете как угодно сделать Никто не запрещает вам разбить парсер на составные, которые будут читать конкретные списки данных. Но нужно ли это? Парсер и так выполняет очень примитивную задачу. Его суть - в отделений модели данных от чтения конкретного формата. Этим со мной когда-то поделился Dimarik на этом форуме. Респект ему.