Smalltalk, for example, implements loops in terms of blocks... so the
reasons are the same as why you'd return from the body of a for loop.

Indeed, it does seem strange if you're doing things for which it doesn't
make sense.  In Java, anonymous inner classes are used almost
exclusively for things where returnings from the enclosing context
doesn't make sense.

What I think you are missing is that in a language with proper support for
closures, and where the APIs make good use of closures, the most common uses
(by far) do not outlive the context that created them.

For instance, in Smalltalk, the normal Collections API includes a method called
#at:ifAbsent: -- which takes two parameters, one is the key or index to look
under in the container, the second is a zero-parameter block which will be
evaluated if and only if there is no such key.   A common pattern in Smalltalk
code is for the caller to invoke #at:ifAbsent: to attempt to retrieve a value,
passing a block which just causes the caller to return.  Thus the method will
"early-out" if there is no such key.

(Other patterns exist too, for instance there are Collections method
#at:ifAbsentPut: and #at:ifPresent: which also take blocks.  Indeed this kind
of use of blocks is pervasive in Smalltalk-style APIs).

Smalltalk does not have the notion of breaking out of a loop, or of
"continue"-ing a loop, but Java does, so in Java (if it had what I would call
proper closures) it would be natural to be able to include "break" and
"continue" statements in the code blocks too.

Note that the "closure" property of closures (that they "close over" the values
of variables) is not important for these purposes.  It is -- of course -- vital
that the code snippets that form blocks be able to read and re-bind the values
of variables in the enclosing scope(s), but that is more-or-less orthogonal to
the property(ies) I'm talking about here.

   -- chris

Not to me.  Continuations are a completely different beast.

That's what "closure" means in contexts where there is nothing /but/
functions/expressions.  The point I'm making is that in Java there are other
"actions" available to code which are /not/ restricted to the evaluation of
expressions (in an environment).  Hence the proper generalisation of
what-Lispers-call-closures would (or at least should) not correspond exactly to
the Lisp concept.

Perhaps a better way of stating it is that what's needed is a way of creating
code snippets that may not be executed immediately.  In Smalltalk such things
are called Blocks (or some similar name), and they are universally seen as the
Smalltalk version of Lisp closures, but in fact they have richer semantics,
because Smalltalk does not even attempt to be a pure functional language.  To
the extent that Lisp is pure functional (or to the extent that any given use of
Lisp is pure), the notion of a "closure" precisely captures the notion of
"postponed code snippet".

   -- chris