I think it can be useful for processing that is clearly separated into stages. You can read it forward:

    foo
        |> do_this_first
        |> then_do_this
        |> this_must_absolutely_be_last

    this_must_absolutely_be_last (then_do_this (do_this_first foo))

> With regard to implicit names (4), I think I actually prefer writing lambdas with my own variable names

I would agree, especially because "it" is not a very good name in some cases. "it.length == 5" is really jarring. In Smalltalk, the custom is to name the variable "each", so for the article's examples you would get "each length = 5" and "each toUpperCase", which look nicer IMHO.

> Isn't destructuring (5) just an effect of ADTs?

Do you mean algebraic data types? I think ADT typically refers to abstract data types, but I'm old. Anyway, yes, destructuring is just syntactic sugar for a pattern match where there is only one variant, so the match can never fail.

> Definitely a fan of auto-currying (9).

I'm a fan of writing and using curried functions by default. I'm not a fan of Reason's syntax that suggests the opposite.

> Is method extension (10) similar to overriding the "magic" double-underscore methods in Python, such as `__add__`?

No. It is adding a new method to an existing class from someone else's library.

  foo do_this_first then_do_this this_must_absolutely_be_last

Yes, but that would be throwing the baby out with the bathwater. Just because of a single operator that I'm not sure is useful in a language I'm otherwise satisfied with.

> where everything is postfix

Except for parsing words, which are commonly used to change exactly this property of the syntax, no?

The fact that postfix is nice in many cases does not imply that postfix is always a good idea.

Isn't the pipeline operator infix?

> In Smalltalk, the custom is to name the variable "each"

Ooh I like that! I think I would like it even more if "each" was a reserved word, like "this" in e.g. Java. But maybe that's a bit much.

> Do you mean algebraic data types?

Yes, sorry. I talk to functional people a lot so we tend to use "ADT" for the algebraic ones (those FP people are all about brevity it seems).

Glad to have that confirmed, though. Just wanted to be sure I wasn't missing something.

> I'm a fan of writing and using curried functions by default. I'm not a fan of Reason's syntax that suggests the opposite.

Could you clarify a bit? I'm not sure I follow exactly what you mean about the syntax being unclear. It seems similar to Haskell, except with parentheses, which doesn't seem terrible.

> No. It is adding a new method to an existing class from someone else's library.

Oh I see! I totally misread that example. Thanks for the clarification!

That's the point: In Haskell, the parentheses (and especially the comma) are meaningful, and "foo(x, y)" is not the same as "foo x y". Reason jumps through extra hoops to make the two syntaxes mean the same thing. To a Haskell (or OCaml, or other ML family) programmer, the Reason syntax suggests an uncurried function.

One feature that always impressed me is how Kotlin has bring-your-own-chaining methods defined on everything.

    request(url).let { req ->
        req.setQuery(mapOf("a" to 42))
    }.let {
        it.body = "foo"
    }.apply { // `this` is implicit receiver inside apply() 
        send() 
    }

Caveat: I'm not aware of any language that actually does this, likely because redefining the core syntax of function application would be so easy to abuse.

EDIT: Removed my Haskell example, because I think I got it wrong.

If you do need it, though, you can make a 1-arity function whose only argument is a tuple of a given size. This is how methods from C# and VB libraries are presented. I believe that it just compiles to a non-curried function behind the scenes.

Introducing implicit variable names is my most hated "modern" feature. I still explicitly write down the default name.

The only defensible way to implement this is by making "it" a keyword and allowing you to access the outer scopes with a syntax like "outer.it" the same way some languages support "outer.this" or "outer.super" when you want to explicitly access the parent class of a nested class.