Protect your REST APIs with JWT tokens

I will be heading to the OWASP Summit this weekend, looking forward to improve my understanding of web security. I have a special interest in securing REST API calls, so I called a working session on this topic. The main objective is to whip the OWASP REST Security Cheat Sheet into shape. The first thing that caught my eye is its section on session management, stating

RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie.

My immediate reaction was: no, REST services should be stateless. Session management does not come into it.
To be fair, I think the authors were mainly concerned about keeping credentials confidential, as they follow on with

Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

Which is fair enough.
Nonetheless, I think there is plenty of room for confusion and I would like to explicitly state that REST services should not be called in a session context, but that each call needs to be authenticated and authorised. In practice, this means a JWT token.
The JWT standard relies on JOSE headers and this can be problematic, but it's the best we have. Let me explain: JWT tokens are self-contained, meaning that they carry all information needed for

1. validation
2. making access control decisions. 

The alternative is so-called opaque, A.K.A. reference, tokens, which need to be sent to a trusted party for de-referencing. This additional round-trip is problematic as network latency almost always dominates turnaround time of REST calls. Performance trumps security, so do not fight it.
JWT is the only well-supported self-contained security token standard I am aware of, so that's what I would recommend in most cases.