Мое упущение: в пять раз - это без оптимизаций методов Read/WriteXXX (т.е. без убирания использования Move) и оптимизации работы со стеком. В два раза - это с упомянутыми оптимизациями. Т.е. классовая структура все-таки накладывает лишние операции и проверки, которые уже могут быть учтены в самом MathParse. (Причем, вопроса о самих накладках вообще не стояло, вопрос стоял только в соотношении: насколько велик оверхед).

Описываемая прадигма разработки, конечно, хороша. Как мне думается, главное - знать когда остановиться. Т.е. не стать космонавтом архитектуры, а вовремя вспомнить и начать писать код. (Оптимизировать, кстати, можно и до уровня ассемблера Но это уже не наша задача ). Но чтобы в совершенстве овладеть этой прадигмой, надо все же накопить побольше опыта, чем у меня. А опыта не прибавится, если я буду просто брать уже готовые решения.