For OAuth 2.0 we’ve deliberately chosen to only support the code grant type because it is the most suitable grant type for our API access model. All our APIs require an app to act on behalf of a user so it is appropriate that users (resource owners) explicitly grant consent to those apps as part of an authorization flow.
No, we've chosen to implement short-lived tokens with long-lived authorizations. This will beneficial for our performance at scale.
Additionally, there is more risk associated with long-lived tokens in OAuth 2.0 because they are the only authorisation required to call the API. OAuth 1.0a also required a private key to generate the signature which was checked on every request.