Point free when done with _andThen_ instead of _compose_ isn't that much different from reading basic statement oriented programs delimited by semicolons:

    (
      f andThen 
      g
    )(x)

vs a = f(x); g(a);

_andThen_ is of course just compose with the arguments flipped such that you can compose from left to right instead of right to left.

In FP languages, and languages that use FP combinators, it is usually more efficient to use composed functions with combinators that do iteration and copying like _map(list, f):List_, because the iteration and copying happens during each map application:

    map(map(l, f), g)

and

   map(l, f andThen g)

produce equivalent results, but the second is faster and has fewer allocations.

For determining the arguments to f and g and map, typed fp languages usually have ide features which can show you the inferred type of each expression, or you can jump to the definition and see it, usually by hovering or key chord while the cursor is over it.

    map[A, B](
      fa: List[A], 
      f: A => B
    ): List[B]

and etc.

This allows you to read things easily and avoid cluttering the code with types where they can be easily inferred.

Point-free style is important to make the usage of such combinators acceptable but experienced devs do extract and name a composition when it becomes difficult to understand. Of course, the treatment of functions as effect-free black box transformers for equational reasoning also makes these refactoring extractions to variables safe to do.

You get a feeling for what is too much over time, and settle on when to use point free style and when not to.

On efficiency - good compilers can often identify nested/chained map applications and rewrite them as a single map application during compilation, but map fusion isn't guaranteed by all compilers or all _map_ instances. The evaluation strategy (lazy/eager) of the language and/data structure also plays a role in whether or not map fusion with point-free style is more efficient or optimisable.