I think the points raised in @ConorMancone 's self-answer are all good and helpful.  Thanks, Conor!

The one thing I would add is that CSRF protection is necessary <i><b>only</b> in the domain and path of the cookie</i> in question.  Or put another way: 

Authorization != Authentication<br/>
Cookies == Authentication<br/>
Token == Authorization

This is relevant to the implementation of persistent logins (your 3rd point).  If you affix your cookies to `login.example.com`, which hosts your login UI and your `/authorize` endpoint, then you can run an implicit OAuth flow every few minutes without requiring a new login (e.g. no password dialog).  The client can go ahead and send the access token thus acquired to `api.example.com` without CSRF, as no cookies will be sent to that host.

So, you can still safely avoid dealing with CSRF on your REST APIs.  But your login / authentication server better be bullet-proof (and CSRF protected).