В первом примере (императивном), у Вас объект класса Calculator после создания хранит в себе состояние: this.VAT = 22. И все последующие методы этого класса работают с этим состоянием (контекстом класса).
Во втором же примере (функциональном) - напротив, никакого состояния у класса нет. Он, по сути, являет собой отдельный неймспейс для чистых функций. Функции в своей работе абсолютно не затрагивают состояние объекта.
Вообще, ИМХО, пример просто плохой. Добавьте в оба примера логику мутации (изменения) VAT, и Вам сразу же станет понятно в чём различие. Ибо в первом примере Вы будете напрямую изменять this.VAT, и использовать его потом. А во втором примере, Вам придётся прокидывать значение VAT параметром, нигде его не храня.
А отличие functional reactive и imperative reactive подходов в том, что:
1. В функциональном подходе Вся ваша программа - это, по сути, одна большая чистая функция, составленная из композиции многих маленьких (как формула в математике), и по которой данные, по сути, текут, преобразовываясь в нужный результат на выходе.
2. В императивном же подходе у Вас данные размазаны по отдельным живущим сущностям, у которых есть своё внутреннее состояние, и которые общаются между собой. Реактивность тут только в том, что у этих сущностей свойства реактивные, то есть при изменении свойства, все зависящие от него сущности перевычисляют зависящие свойства/значения.
Разница, как таковая, не в реактивности, а всего лишь в способе декомпозиции задачи. Реактивность что там, что сям, по сути одна и та же (в примере: Rx.Observable.from(items)).
