Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží
Ne, nezáleží na kontextu, nemaťme pojmy. Funkce f aplikovaná
kdekoli na stejné argumenty dává stejný výsledek. To je princip FP a jeho hlavní deviza. U různých FP jazyků je to různě striktně dodržováno, ale v principu se to dodržuje všude, kde není pádný důvod to nedodržovat.
, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje
Neexistuje. V OOP nikde nemáte mapu, že metoda M1 objektu O1 používá metodu M4 objektu 04, pokud si ji nějakým spešl toolem nevygenerujete z AST.
Vezměte si libovolný středně velký OOP projekt určený pro jednovláknový běh, na pět náhodně vybraných míst dejte nějaký ten skok do jiného vlákna a celé to pusťte na sto vláknech. Jestli dokážete předem přesně identifikovat místa, na kterých může dojít k nějakému problému, tak jste buď geniální, nebo lžete. Spíš ale lžete

Abyste to udělal, musíte ten kód kompletně projít, analyzovat si stromy volání a pravděpodobný výsledek bude, že všechno v důsledku volá všechno, takže problém může nastat kdekoli.
Čili u OOP i FP máme jeden společný pseudoproblém "když změním chování fce, tak se změní chování fce" a navíc má OOP jeden megaproblém, na který se v praxi naráží.
Erlangovský program můžu spustit na kolika chci vláknech a nestane se vůbec nic. Protože neexistuje způsob, jak by si procesy mohly do stavů šahat. Prostě není. Funkce přijímají data a vrací data, sdílená data neexistují (kromě databáze) a s procesy se komunikuje výhradně zprávami.
Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat.
To není potřeba si představovat, stačí se podívat na ejabberd. Je z něj po (více než) deseti letech jeden z nejúspěšnějších jabber serverů (ne-li úplně nejúspěšnější).