I don\'t know if I just have some kind of blind spot or what, but I\'ve read the OAuth 2 spec many times over and perused the mailing list archives, and I have yet to find a
It's there for security reasons, not for simplicity.
You should consider the difference between the user agent and the client:
The user-agent is the software whereby the user ("resource owner") communicates with other parts of the system (authentication server and resource server).
The client is the software which wants to access the resources of the user on the resource server.
In the case of decoupled user-agent and client the Authorization Code Grant makes sense. E.g. the user uses a web-browser (user-agent) to login with his Facebook account on Kickstarter. In this case the client is one of the Kickstarter's servers, which handles the user logins. This server gets the access token and the refresh token from Facebook. Thus this type of client considered to be "secure", due to restricted access, the tokens can be saved and Kickstarter can access the users' resources and even refresh the access tokens without user interaction.
If the user-agent and the client are coupled (e.g. native mobile application, javascript application), the Implicit Authorization Workflow may be applied. It relies on the presence of the resource owner (for entering the credentials) and does not support refresh tokens. If this client stores the access token for later use, it will be a security issue, because the token can be easily extracted by other applications or users of the client. The absence of the refresh token is an additional hint, that this method is not designed for accessing the user resources in the absence of the user.