Как функци-анальщик (велик и могуч русский язык) не соглашусь.

Во-первых, я перешёл с функциональной Scala и JavaScript больше ФП, чем ООП в современном виде. forEach / map / flatMap в Scala используется и в хвост и в гриву, и на производительность никто не жаловался.

Во-вторых, это заблуждение. На современных движках эти forEach / map / flatMap по производительности отстают от for of в 2 раза, грубо говоря. Это вообще ничто учитывая производительность, если не ворочать миллионами объектов.

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

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

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

Все доп. библиотеки обработки данных типа rambda заточены под ФП и переиспользование кода офигенно.

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

И React это "чистый" ФП... функции... функции функций и т.д.

Да, я лучше список пробегу фильтруя, чем буду тр...ся с Set. По-сути нужно создавать новый Set из старого.

Можно, конечно извратиться используя useRef ссылки, но оно того в 99.99% не стоит.

Те это не моё нежелание, а невозможность / ограничение фреймворка (думаю у других не лучше).

И вообще если вы работаете с миллионными списками вы что-то делаете очень неправильно. А со списком в 100 элементов из БД...его хоть как медленно обрабатывай это миллисекунды.

Наверняка в Node.js другая ситуация, но там гораздо больше ООП, сам API этому способствует.