This is true, however in most programs, the entities that map directly to stateful entities in the “real world” are in a minority, and the bulk of the program consists of entities that serve the program’s implementation needs.

Those can be written in any style we like. For example, in languages like JavaScript and Ruby, if we wish to compose classes out of smaller components, we can imperatively modify classes, or we can write functions that take existing classes and return new classes consisting of the originals composed with whatever additions we desire.

What I am trying to say is that while imperative may feel more natural for problems involving state and time, we often perceive that problems require state and time even when they don’t.

---

I can fully accept the argument that people don’t like FP because they perceive that their problems need imperative solutions. But that is not the exact same argument as “people don’t like FP because their problems involve space and time."

OK I think that's a good and useful point and a motivator for learning FP. Nevertheless because most people continue to perceive things imperatively and because as the article says FP is puzzle like then the author still is probably right when they say that FP will remain unpopular.

I like "solving puzzles" but I don't like solving them under pressure. I also don't like deciphering someone else's puzzle when I am in a hurry and when I'm unlikely to never need this piece of code again. So even for people who like puzzles it's often the case that they just need to get something working fast that's reasonably correct.

The fact that life is short and that the world changes so rapidly is what makes worse better.