OAuth2 access tokens do not have to expire (or rather they do, but it can be many years hence).
An access token can be used ONCE to acquire certain resources from the resource server, in particular, it allows for the acquisition of those resources approved by the user. A refresh token on the other hand allows repeated access. Thus one cannot do away with refresh tokens without requiring user interaction between every access.
In general though, tokens can sometimes be stolen by other malicious apps on the same device, or by MITM attacks on the phone. SSL is MITM-able if the phone can be made to trust a dodgy certificate. This is sometimes required by companies to access internal networks (they require the acceptance of a self-signed certificate, which allows them to MITM all encrypted traffic occurring over the company network. Thus assuming sending the tokens encrypted means they cannot be stolen en route is dangerous.
Bearer tokens are no weaker than any other form of token per se, as proved in a bunch of papers (including one of my own, which I'll post the link to when I can dig it out.) However, bearer tokens are only appropriate in cases where the assumptions they make are valid. The assumption that the token can be kept secret is a primary assumption of bearer tokens in general. If this is not true then bearer tokens do NOT assert ANY security properties (although some do still hold). See NIST Level 3 tokens, which define what attacks bearer tokens must defeat, as specified in OAuth Bearer Tokens. In short bearer tokens are not supposed to defeat theft of the token.
Bearer tokens cannot be revoked, it is true. However given that the usual pattern of access is to use the access token immediately after acquisition, one should expire access tokens fairly quickly to prevent potential abuse, even if an abuse case cannot be thought up currently. The longer a token is around the more likely it is to be stolen. A refresh token is in fact much more dangerous to have stolen, as it provides repeat access over a longer time frame, if you cannot secure the client id. OAuth2 can provide access to resources in general, and thus for example could be used to expose APIs to a client for a time. With a refresh token significantly more damage can be done, as opposed to a single use token.
Client authentication can in fact be made more secure in a number of ways, for example, giving each client on download a different key. This prevents generalized attacks where reverse engineering a token on one device breaks the security for all instances of the client. Other potential techniques include using OAuth to verify the client with your server, which then performs a second run of the OAuth protocol with the authorization server you wish to access. This then lets you have clients that update their keys regularly, and for them all to have different keys, whilst not placing undue burden on the systems used by the Authorization server owned by Facebook or Google for example.
When using a mobile app, long-lived refresh tokens is more secure than having some sort of multi-use bearer token, even if one does not take steps to secure the client. This is because the user cannot expire the token. If the refresh token is not stolen, and the user merely wishes to revoke access then this can be done. A multi-use bearer token cannot be revoked even if the user merely wishes to revoke access. A multi-use database reference token can be revoked obviously, but this is not what the protocol is designed for and thus the security analyses that have been performed on OAuth do not say anything about the security of this hybrid system.
In conclusion I would recommend using refresh tokens and database tokens, as this is the most likely to be secure. If you can do anything to secure the client that's a bonus, but the situations this protects against are minimal. If you do want to secure the client consider soft tokens, a la google authenticator, as this is a solid implementation that has withstood analysis by some very smart people.
