I have to confess I've had this question for a very long time and never really understood.
Say an auth token is like a key to a safe; when it expires it's not usable anymore. Now we're given a magic refresh token, which can be used to get another usable key, and another… until the magic key expires. So why not just set the expiration of the auth token as the same as refresh token? Why bother at all?
What's the reason for it? Is it a historical one?
The referenced answer (via @Anders) is helpful, It states:
In case of compromise, the time window it's valid for is limited, but the tokens are used over SSL, so unlikely to be compromised.
I think the important part is that access tokens will often get logged (especially when used as a query parameter, which is helpful for JSONP), so it's best for them to be short-lived.
There are a few additional reasons, with large-scale implementations of OAuth 2.0 by service providers:
API servers can securely validate access tokens without DB lookups or RPC calls if it's okay to not worry about revocation. This can have strong performance benefits and lessen complexity for the API servers. Best if you're okay with a token revocation taking 30m-60m (or whatever the length of the access token is). Of course, the API servers could also keep an in-memory list of tokens revoked in the last hour too.
Since tokens can have multiple scopes with access to multiple different API services, having short-lived access tokens prevents a developer of API service for getting a lifelong access to a user's data on API service B. Compartmentalization is good for security.