Я бы определенно приступил к реализации вашего первого подхода, потому что это звучит ясно и легко.
A Dictionary<int,Field> кажется мне очень хорошим, может быть, заключен в классы FixMessage, предоставляющие такие методы, как GetFieldHavingTag(int tag) и т.д ...
Я не знаю протокол FIX, но, глядя на ваш пример, кажется, что сообщения, как правило, короткие, а также поля, поэтому давление выделения памяти не должно быть проблемой.
Конечно, единственный способ убедиться, что подход хорош для вас или нет, это реализовать его и протестировать.
Если вы заметили, что в случае большого количества сообщений метод медленный, то профилируйте его и найдите, в чем / где проблема.
Если вы не можете решить это легко, тогда да, измените стратегию, но я бы хотел реализовать идею, что вам нужно сначала протестировать ее, затем профилировать и в конечном итоге изменить.
Итак, давайте представим, что после вашей первой реализации вы заметили, что при большом количестве сообщений распределение строк замедляет вашу производительность.
Тогда да, я бы выбрал подход, аналогичный вашему третьему, давайте назовем его "подход по требованию / ленивый".
Я бы построил класс FixMessage, принимающий строковое сообщение и ничего не делающий, пока не понадобится какое-либо поле сообщения.
В этом случае я бы использовал IndexOf (или что-то подобное) для поиска запрошенных полей, возможно, результаты кэширования были бы быстрее в случае другого равного запроса.