Not something I said. I explicitly mentioned the functional core, iterative shell architecture, and explained how you need to understand functional enough to know when it's a good time to not use it.
At this point your posts look like someone making fun of a complex technology they do not understand, without really approaching any valid criticism of its real shortcomings, because such criticism require a thorough understanding of the thing being criticised.
> Functional programming that introduces or models state requires more abstraction, and then complexity.
I'm pretty sure I've said exactly that. Good thing we agree on it. But you don't seem to realize that this fact is only true for handling state, and not for other aspects of programming.
> Imperative programming with state is as simple as functional programming without state.
You've never tried to compose multiple asynchronous event streams of complex data types from different subsystems into one single user-facing unified presentation, have you? Your assertion is simply not true. Such feat is way simpler in functional reactive style, and a true nightmare in an imperative multithreaded program. That's why web frameworks are evolving to handle more and more reactive functional patterns for compositional asynchronous tasks.