Производительность слишком высокой никогда не бывает. Энергопотребление никогда не бывает слишком низким.
И это не исключение для любого проекта

Запас же по производительности всегда приятен

А на счет вью/реакта - вероятность слишком низкой производительности это постоянный фактор и всегда необходимо помнить про то, что её может не хватить и иметь общее понимание о способах оптимизации.

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

Особенно удобно и приятно когда пилишь красивенный(по субъективным меркам) сайт (на свелт в данном контексте) и понимаешь что он не лагает даже на слабых устройствах и не нужно просчитывать этот случай и выключать анимации или тратить время на оптимизацию

Приятно думать что твой апп производительней, чем у других)
Думать о производительности, когда нет проблем с производительностью это конечно мощно. Большая проблема когда всякие джуны начитаются статей с бенчами и потом бегут делать свой супер апп на супер производительном фреймворке, набивая проект под завязку зависимостями с 5 звёздами на гитхабе.

...производительнее чем у других

Я хз к чему эта фраза здесь.

Думать о производительности, когда нет проблем с производительностью это конечно мощно

На виртуалдомовских фреймворках с рантаймом это просто организовать.

В итоге либо процесс оптимизации происходит попутно с разработкой и рефакторингом(сделал компонент - затестил компонент и его производительность) либо в конце проекта.

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

Тобишь ни один из вариантов ничего хорошего не несет. Только потраченное время.

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

Касается это любых джунов и умение правильно находить информацию о требованиях к инструментам разработки необходимо(и в конце концов если джун не знает как выбирать инструмент то есть всякие тостеры, статьи на хабре и прочие).

И джунов от выбора "неправильного" инструмента не спасти, если он не знает что он хочет создавать

Под инструментом я также подразумеваю языки как таковые

Ну да оптимизация производительности это обязательный пункт каждого проекта. Один я такой фигак-фигак и в продакшн.

такая странная дискуссия :)
почему бы просто не остаться при своём и не продолжать наслаждаться теми преимуществами которые были обнаружены? :)

Ситуации бывают разные и вероятность того что какой-либо тим лид(или одиночка фрилансер...) неправильно расчитает время разработки точно не нулевая

будь то продакшен-рединесс реакта, или производительность свелта

Ынтырпрайз-мастхевнесс

Уж скорее

JQuery, особенно последних версий, это супер легкая обёртка над Dom api. Там нечему тормозить и нечего оптимизировать. Однако само приложение на нем можно написать плохо, так как сам JQuery никак не помогает в этих вопросах. Современные фреймворки как бы берут на себя ответственность за эффективные манипуляции с DOM. И кто-то это делает лучше, кто-то хуже, а кто-то совсем плохо. С тем же реактом и вдом почти не наблюдается проблем на современных десктопах, но как только речь заходит о мобильных, ТВ, embedded и low-powered то проблемы сразу встают во всей красе.

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

Кхм... Сайдбар фигмы... Кхм

Или что там лагающее на реакте сделано)

Разрыв шаблона

Да конечно есть) просто для некоторых проектов это норм и даже 2-х мб бандлы в порядке вещей.)) для больших штук или приложений не публичного характера, иногда важнее DX , чем UX. Как ни крути, то реакт это стандарт индустрии сейчас и конечно DX в широком смысле (набор решений, практик, инфы и тп) у него опережает свелт