Abstractions exist in our brains. They are costly when they are unfamiliar (requiring learning) or when they are inappropriate (the product of incompetence and causing pain for everyone). Sometimes they are exactly as costly as they should be, reflecting the inherent and essential complexity of the problem, which is ideal. Inappropriate can mean either “too little” or “not enough”… but more accurately, it just means “the wrong abstraction”. Making everything a class, or treating everything like a Turing tape, is also creating mountains of almost-certainly inappropriate abstractions, in most (but not all) cases.

This is very handwavy, because i’m speaking in very general terms. But for a single, narrow, non-general, concrete example, just look at the ORM impedence mismatch problem with OOP languages. AFAIK, after 40-some years it’s still unsolved. I don’t believe FP suffers from this specific problem (again, just to give a concrete and non-handwavy example), because FP is very analogous to relational programming (functions are a special case of relations).

This shouldn’t be so controversial and should be very intuitive to anyone who spends a bit of time thinking about it. A function is fundamentally a simpler building block than a class. It’s more atomic.

I don't believe an ORM is a zero cost abstraction either. Or most of OOP.

The cost of implementing everything as a function is when one has to contend with the fundamental machine architecture not dealing with everything as a function. This often leads to one of the highest cost abstractions out there, the Monad.

There is no reason to use state at all here, let alone the state of the world. In FP you just do:

    x + 1

Moreover, this example is totally meaningless, because it doesn't feature anything that is different about FP and the imperative style at all.

y = x + 1 is not dealing with state. Supposing there was a desire to have x = x + 1, the simple way of doing this is x = x + 1, and the complicated way is to do world = Increment(x, world).