Assuming the service maps cleanly to the HTTP verbs, which if it does he says by all means use a RESTful interface, but if not, don't be afraid to make it non-RESTful.
One that comes to mind is a service with semantics that require a preview step. Sure you can use create/read/update via the REST verbs, but I think a lot of the confusion on this issue comes from wanting to embed the concept of events, so a read may be for the purpose of previewing an item, but it feels more natural to fire a "confirm" event than to do a post with a field called state=cofirmed.
At least that's my personal opinion. I agree that any service can be mapped given sufficient creativity, but it often seems like extra work in the context I described.
Obviously there are cases when there's more than one way to change the state of the object that are only relevant to that object type. In the web world usually the full object state is already on the client so it is not a big deal. You can have your special methods in the client side library and still expose only CRUD methods in the service API.
Sending email is best mapped to POST (create), not PUT (update), and the URL doesn't change for POST.
What I find annoying is people objecting to "POST /actions/subscribe" (with the params in the post body) because it's "non-RESTful" -- the url is a verb and REST demands a noun.
That way you can list your subscriptions, modify, delete in a very consistent way, without a need for "POST /actions/modify_subscription" and such.
POST /actions/subscribe
POST /subscriptions
POST /abcdef1234567890