2) I'm using it primarily from JavaScript AJAX calls, where the user
is already authenticated.  I'm using it instead of actions because
there's less overhead setting one up and actions always do a forward
after the action finishes.

3/4) I will need some external authentication, but the lack of a good
template and time to figure out usage on my own has preventing me from
using it just yet.

5) I'm only using REST; haven't yet had a need for a different kind of
service (although examples of the others might spur my imagination).
For services that are simply alternative approaches to IPC, I don't
know that providing N options buys you anything but confusion.  Go
with one and make it work flawlessly, rather than half-assed
implementations of several.

6) The actual responses look kind of verbose (I think in JSON there's
an object with a single "api" field, which has "result" in it; the
extra level seems extraneous).

There are no good examples of error handling.  The typical ways of
signaling an error in PHP (throw an excaeption, return false) all
result in the API failing, instead of generating an error result.  I
figured out the only way to return an error is to return an
ErrorResult; it'd be nicer to simply throw an exception and have the
REST handler handle the error.  That way my exposed functions can be
used by regular code without having API warts on it.