Only the syntax, and it’s ugliness — it’s ugly because you don’t understand it at a glance. Once you’re used to the syntax, and you can grok the intent of the code at a glance, it may not stick out as ugly. A certain amount of syntactic decoration is necessary to fit it into a language that wasn’t originally designed for it, in order to make it forward-compatible.

In my opinion, one thing that really makes the BGGA closures powerful is the change of semantics for return, break, etc. It allows easy-to-write iteration using recursive algorithms, for instance: imagine you have a tree-based structure and you want to iterate through nodes or leaves of the tree. Today you have but one choice: to write an Iterator class, which un-recursifies the iteration. About 100-300 lines of code (!), which are quite tricky and hard to make bug-free.

With the BGGA closures, you just need to write your recursive algorithm (which is usually much simpler and shorter: down to 15-20 lines for classic tree-based algorithms?), and invoke the argument closure at every step of the iteration. If the closure decides to stop the iteration after the first or the second step, it’s very easy to do it, no matter the recursion depth: the recursive algorithm doesn’t have to be rewritten for that.

The best example I found on this matter is Neal Gaffer’s one on his blog: http://gafter.blogspot.com/2007/03/closures-for-organizing-your-code.html

http://www.artima.com/weblogs/viewpost.jsp?thread=202004

    Collection publishedBooks = select(books, {Book book =>
        book.isPublished()
    });

…and for closures that do not need to result in an expression, I could choose between the standard and the control invocation form? Isn’t that confusing? If you get used to the control invocation syntax, wouldn’t you want to use it in all cases?