1. "не по назначению" - это про концепцию. совершенно безумная идея перенести реакцию на события браузера на сервер.

2. "кроме самого фреймворка" - это прекрасно, что вам подходит для своих задач. только сдаётся мне, что будет очень больно сделать из этого что-то кастомное (не ваше), даже приняв безумную концепцию

3. react, vue, для любителей экзотики - svelte, google incremental dom. ну и что там по списку в этом году.. даже vanilla js или jquery подойдёт - у вас там совсем немного функциональности. все эти россказни про "ни строчки js" улетучиваются, когда клиенту нужно срочно что-то сделать не так, как вы придумали. тогда бедолаги, наслушавшиеся про "ни строчки js" срочно ищут js-макаку и г-нокодят "идеальную" систему.

далее, я уже писал про древние подходы - так вот они намного выигрышней вашего, т.к. не утилизируют с безумной силой сеть. в вашем демо-приложении из п.2 очень мало контролов и нет зависимостей между ними и то на каждый клик в options как минимум 2 http запроса. если взять более-менее приближенный к реальности вариант, то это будет провал.
вам в комментариях к новости писали про тонну запросов ютуба - это же в основном обязательная аналитика, всякое seo и прочий маркетинг (для публичных сайтов - это, к сожалению, уже неизбежно). если к этому потоку данных прибавить ещё по 2 запроса на каждый клик интерфейса (а если клик вызывает изменения, затрагивающие не один контрол, а какое-то сложное изменение интерфейса), то 3g соединение может и потянет, но будет очень больно. можете даже на своём tiny-demo сайте из п.2 в chrome dev tools выставить ограничение соединения и посмотреть как ваш примитивный интерфейс в options работает:)

после этого пройдите на реально здоровые сайты.. даже не будем о больном - о фейсбуках.. зайдите на алиэкспресс. если мне не изменяет память, там всё взаимодействие висит на старых добрых jsonp-колбэках.

не спорю, что подход пуси, а тем более korolev - это ново и самобытно, лысенко тоже новые и самобытные вещи утверждал в своё время