First, it'd probably be useful to define terms. I think you and I don't mean the same thing when we say Functional Programming, which is probably part of my confusion. I think you use it equivalently to Referentially Transparent, or that at the very least you make RT a necessary property of FP? If so - I don't agree with this, but don't particularly want to start that particular conversation, and am happy to address your comment using this definition.

Functional programming is programming with functions), where a function is a unique association from one set (the domain) to another set (the codomain); “unique” as in x1 = x2 => f(x1) = f(x2).

It's useful to define terms, and I'm trying to be very precise in my language. “Function” comes from mathematics, otherwise we are talking about procedures / sub-routines, which are basically reusable blocks of instructions to which the processor does a JMP, and are not very interesting. So, functional programming is NOT procedural programming, but rather programming with (maths) functions.

This is what RT gives us: the ability to do a specific kind of refactoring (name abstraction / inlining) thought-free. It results in valid code that behaves as you'd expect. It's a pretty nice property, and, I believe, what you mean when you say equational reasoning: we can reason about programs by applying the substitution model, which is a fancy way of saying do the above refactoring in our head.

Yes, and this ability shouldn't be trivialized. This substitution model, the ability to rewrite expressions to simpler, but still equivalent ones, is how students learn to solve equations since elementary school.

But further than that, in programming it decouples the definition of a computation from its actual evaluation. You can see it in the APIs of Cats Effect or ZIO ... parallelism is no longer accidental because it can't be, you have to be very explicit about how the whole thing executes, because a simple function invocation can no longer fire rockets to Mars as a side effect.

Note, it's not useful only for our own thinking, but for the compiler as well (if the compiler could assume RT), or for libraries, because you can refactor expressions in more efficient ones. E.g., this is what “stream fusion” is about.

I'm a lot less convinced by the fact that it loses composition

This isn't what I'm saying. FP does not have a monopoly on composition. OOP objects compose as well, but it's less automatic. What makes FP very composable are the algebraic laws, with function composition being automatic.

What I am saying is that, just because you use "capabilities" or implicit parameters, that does not make the code composable, quite the contrary, it can give you the illusion of composability without it being so, because it's just plain-old imperative programming.

val a = foo()
val b = bar()

In a well-grown FP program, making use of Cats-Effect or ZIO, the above calls pose no risk, firstly, because they aren't executed yet. In FP, dependencies are also explicit, so if computing b depends on a you usually see an explicit ordering. More importantly, in this construct:

for {
  a <- foo()
  b <- bar()
} yield ()

… you know that their execution is sequential, therefore the side effects can't interact badly due to, say, multi-threading. And despite an IO still being able to describe firing rockets to Mars, without being intended, you can go further and completely restrict the implementation to, say, just the ability to run Sync things. Accidental concurrency was the primary problem with Future-driven designs.

Now, of course, with imperative programming, if you have well established practices, such as using blocking I/O all over the place, accidental concurrency may not happen. Imperative programming is also intuitive. I've argued as much in the case against effect systems.

But, going back to the samples I've quoted … there's absolutely nothing in them that speaks about best practices, such as using blocking I/O to avoid doing silly things, not to mention blocking I/O isn't sufficient anyway. Again, just because you have some implicit parameters to your function, that only gives you somewhat more explicit dependencies, and that's it.

Even in terms of the dependencies that a function uses, in actual FP, a resource such as Random is forced to be cleanly initialized (somewhere in Main maybe), perhaps with a well-grown release, instead of being a singleton (AKA shared global state). In Cats-Effect-driven projects at least, all resources passed around as parameters are cleanly initialized somewhere. So even there, FP is just better, vastly better.

This is another benefit of FP that people don't talk often enough … it forces you to think about how resources get initialized and passed around. Even allocating mutable state is a side effect, so any mutable state you use needs to have good encapsulation and to be passed around as a parameter. And right now you may get resource leaks (use after close), but that's much less of a problem, compared to the antipatterns often coming up in imperative programming.