oDocumentação do Play 2.2 afirma que:

Devido à maneira como o Play funciona, o código de ação deve ser o mais rápido possível (ou seja, sem bloqueio). Então, o que devemos retornar como resultado se ainda não somos capazes de gerá-lo? A resposta é um resultado futuro!

Um [Resultado] futuro acabará por ser resgatado com um valor do tipo Resultado. Ao fornecer um [Resultado] futuro em vez de um resultado normal, somos capazes de gerar rapidamente o resultado sem bloquear. Em seguida, o Play exibirá esse resultado assim que a promessa for resgatada.

O cliente da Web será bloqueado enquanto aguarda a resposta, mas nada será bloqueado no servidor, e os recursos do servidor podem ser usados para atender outros clientes.

Ações que retornam um futuro são criadasAction.async, em oposição aAction.apply para ações normais não assíncronas.

Existe algum benefício em ter ações não assíncronas? Parece-me que a melhor maneira de garantir que nenhuma das minhas ações seja bloqueada é declarar todas elas usandoAction.async.

De fato, de acordo com oDocumentação do Play Framework 2.3 parece que no Play 2.3 todas as ações são assíncronas:

Nota: Action.apply e Action.async criam objetos Action que são tratados internamente da mesma maneira. Existe um único tipo de ação, que é assíncrono, e não dois tipos (um síncrono e outro assíncrono). O construtor .async é apenas um recurso para simplificar a criação de ações com base em APIs que retornam um futuro, o que facilita a gravação de código sem bloqueio.