Насчёт анимаций: их задумано оформлять через CSS, который загружается один раз (прописью: "один раз")..

Именно по этой причине самая популярная (и безумно оптимизированная) UI библиотека тянет вместе со стилями еще кучу js скриптов, да?
Вы не сможете псевдоклассами дать полную интерактивность, как ни старайтесь, это же очевидно. CSS не предоставляет необходимые возможности, это было известно очень давно, поэтому у нас и есть JS.

но принципиально нового ничего не поменялось. Как 15 лет назад на гугле была погода, товары и новости, так оно и теперь остаётся...

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

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

А можно еще вообще HTML писать, и хранить все на домашнем ПК.
К черту распределение нагрузки, масштабируемость, гибкость и все остальные плюшки, только усложняют нам тут все.
На HTML CSS по канону все написал, без этих вот скриптов дурацких, на сервер по фтп залил да и пошел себе отдыхать.

эм, при чём тут монополия? Веб приложение может иметь один и тот же код что на iOS, тчо на андроид что на компе.

Ладно, про монополии и экосистемы наверное сложно будет сильно. Чтобы перейти от нативного подхода к универсальному нужно уйти от разнообразия и конкуренции, создавать рамки и играть по этим правилам. Тогда универсальность может и будет работать, сейчас же она не жизнеспособна, даже для среднего размера проектов, не говоря уже о больших (и btw это уже прямой путь к монополии рынка идей и продуктов, вот к чему это)

это именно про это. борьба за синтаксис foo = bar и против синтаксиса update_foo(bar) привела к тому, что 80% времени тратится именно на обеспечение этого самого синтаксиса

Я еще раз повторюсь, это разные технологии, это все равно ругаться на кровлю из-за того что вы бьетесь мизинцем об угол тумбочки.

Мало того, этот синтаксис приводит к тому, что то, о чём вы пишете "bar => baz => qux => etc" является связями СИЛЬНЫМИ, хотя могло бы быть связями слабыми.
что такое слабая связь? это когда поломка qux (в Вашем примере) не влияет на работу baz. А в реакте поломка qux (без лишних приседаний, которые поэтому никто не делает) ломает не только baz, но и bar.

Мало того что сильные слабые связи имеют только косвенное отношение к парадигме программирования в целом, так еще и обьяснение вывернуто наизнанку.
Я наверное сейчас вас удивлю НО реактивное программирование СПОСОБСТВУЕТ СЛАБЫМ связям, потому что изолирует работу оператора внутри потока, операторы же тут аналогичны чистым функциям.
Оператор сам по себе не знает о других операторах и работает только с потоком, это как раз таки и снижает связанность.
В тоже время цепочка сама по себе не является сильной связью поскольку описывает минимальную необходимую логику поставленной задачи и связь была бы такой же как и у ~etc(qux(baz(bar(foo))));

именно фреймворк не предоставляет [нормальных, удобных....

Ну во первых фреймверк ничего не забирает, все встроенные функции как были так и остаются, во вторых он только добавляет возможности, уже из коробки, а в итоге вы сетуете на то что вам дали много возможностей

При всем уважении, но у меня складывается такое впечатление словно я стараюсь доказать плоскоземельщику что земля круглая, но он отрицает все аргументы и стоит на своем.

Знаете, есть такое выражение: если от всех и от каждого пахнет какашками, то стоит понюхать свои штаны.

неа, не странно.

Да как же не странно, если очень даже, сама суть что вы вместе с необходимыми данными должны отдавать весь интерфейс, причем каждый раз, причем еще и анимации всякие описывать, зачем это туда сюда гонять каждый раз? Все сейчас идеально - передаём только нужные данные + большинство библиотек из CDN считай уже загружено.
А вот туда сюда повторно гонять - это ну очень странно и абсолютно не логично. Какой в этом смыл? Что мы от этого получим? Я плюсов не вижу.

главная страница яндекс и гугл 15 лет назад так же показывала погоду и новости

ох, совершенно не так, интернет за 15 лет стал совершенно другим, качество другое, скорость разработки, отказоустойчивость, кроссбраузерность, даже сравнивать не вижу смысла.
В нагрузку идут другие платформы, мобильные приложения, интеграции разные с другими платформами и приложениями, все это благодаря тому что у нас есть удобные решения, не идеальные, но очень даже удобные.

никогда не понимал компании держащие отдельно IOS разработчиков, отдельно Android, отдельно веб.

Ну тут долго рассказывать про монополию, конкуренцию и рынок, разнообразие и все остальное.
Универсальность и стандартизация конечно хорошо, но в разумных пределах.
Плюс такая универсальность только вредить будет, туда еще добавьте телевизоры, э.книги, смарт часы и другие гаджеты в таком случае, зачем нам отдельно еще и этих разработчиков держать? Один программист сразу на все платформы напишет.
Только с такой универсальностью, я уверен более чем, мы получим на выходе непонятного монстра которого невозможно будет поддерживать.

то что я могу присвоить foo = bar а оно перестроит гуй (главная фича реактивности, за которую дрались "любой ценой")?

А при чем тут реактивность к GUI? Никакого отношение реактивное программирование не имеет к MVVM, за это отвечают совсем другие механизмы и другие библиотеки.
Реактивное программирование это совершенно другое и не имеет к GUI никакого отношения.
А вот двухсторонняя привязка MVVM появилась еще раньше всех реактов и остальных библиотек, еще во время вебформ уже сделали то что foo = bar будет непосредственно менять представление, а после это чудо решили переносить в ASP.NET но наделали кучу костылей и работало это все из рук вон плохо.
Я прекрасно это помню, как раз таки одна из первых работ у меня была связана с такими системами, ужасный опыт на самом то деле. Я рад что это все заменили столь удобными фреймверками.

А реактивное программирование это не про foo = bar, это про то что foo + operator + bar => baz => qux => etc... Это про потоки и это то как правильно должна описываться логика, потому что именно так и происходит взаимодействие пользователя, бизнес логики, приложения и платформы. Все основано на событиях и на событиях лучше всего описывать логику.

о том, чтобы нормально обработать кнопку "назад" никто и не думает.

что-то я не знаю никаких проблем с кнопкой назад ни в одном фреймверке, а то что люди вместо того чтобы правильно писать роуты, или менять queryParams во время поиска или фильтров - просто сразу делают api запрос и перерисовывают, то это ведь не проблема фреймверка, это проблема специалистов которые такой код пишут.
Как в анекдоте: не любите детей? вы просто не умеете их готовить.
Так и тут, никаких проблем с кнопочкой назад нет, есть проблема в том что люди не хотят читать даже базовую документацию, а учатся по 10-ти минутным роликам в ютубе.
И эта проблема может касаться чего угодно, хоть фронта, хоть бека, всего где нет защиты от дурака.
Так что это претензии уже не к фреймверкам, это к скиллбоксам или как их правильно называют...

Представьте desktop приложение которое загружает весь UIUX от сервера, представьте мобильное приложение которое получает весь UIUX, какой-нибудь Youtube music. Странно будет выглядеть, не правда ли? Почему для вас нормально когда веб получает весь UIUX от сервера? У нас уже давно не web странички, зачастую это полноценные, сложные приложения.

Изначально Web был неправильно спроектирован, сейчас, слава богу, благодаря SPA ситуация немного изменилась.

И как раз таки в первую очередь решает проблему неправильной архитектуры, решает проблему кроссплатформенности, чтобы API работало на все платформы и решало свои задачи.

Решает проблему делегирования задачи.
Full-stack программисты востребованы, но в серьезных компаниях и на крупных проектах работают узкоспециализированные специалисты с углубленными знаниями в одной области - разделение на back-end и front-end это тоже решает.

Даже если условный бекенд будет отдавать вью - все равно вся работа будет передаваться скриптами на фронт, а уж после тут отрабатывать( я про свистоперделки).

А реактивность это пожалуй одна из лучших вещей какие случались в программировании, если мы говорим за парадигму конечно, а не за тот-же redux(не скажу что он идеален). Сам RX восхитителен, жаль не многие хотят им проникнуться, когда ты описываешь цепочки событий - ты закрываешь целые сценарии поведения, это безумно упрощает жизнь и повышает качество написанного кода, уменьшая количество проблем, каждый раз когда меняется А тебе не нужно заботиться о том чтобы поменялось и Б, а в след за ним В. Но вот только я не пойму при чем тут реактивность к вебу и клиент-сайд приложениям?
Но если вы вдруг про React, то помимо реакта есть куча других SPA фреймверков, может вы это имели в виду?

SPA фреймверки это наша надежда на то что веб может стать нормальным, на ровне с другими платформами, и слава богу все к тому движется.

Словами - это ведь писать надо, а люди заняты, свой ноушен пишут. Прекрасная альтернатива - поставить минус в знак несогласия.

Ну да, только вот если люди перестанут работать - они перестанут получать зарплату, у людей не будет денег чтобы покупать товары компании, а если у компании никто ничего не будет покупать - дикие прибыли им не светят точно, а робот с соседней фабрики не забежит, им денег то не платят 🤷🏻‍♂️