OAuth 2.0 Bearer-Tokens vs. Mac-Tokens. Why not using Mac-Tokens?

The danger is that if the client proceeds without insisting on the SSL/TLS certificate being valid - which is a step that many clients fail to take - then the bearer token is susceptible to a man in the middle attack.

The Mac token is not susceptible to this attack; it may be correct to say that the Mac token provides some authenticity in the absence of SSL/TLS, or indeed when it is not being used correctly.

The Mac token strengthens a known weakness of the Bearer token.

A client should not be trusted with a MAC key that is shared. A new key should be generated for each client. It is no more of a security risk to trust each client with its own key, than it is to trust them with bearer tokens.

I think the problem comes when exchanging the Auhtorization Grant for the Access Token. For the Mac key, this returns a symmetric secret key. If the client is sloppy about checking SSL/TLS certificates, then this too is susceptible to a MITM attack.

In short, the Mac token may be less favoured because it is more complicated but you still need to do SSL/TLS right to make it secure, and if you do that then the Bearer token will also be secure.

In my opinion, the answer may be simple: Bearer token mechanism assumes existence of SSL/TLS layer, whereas MAC token tries to replace that. Since SSL/TLS is widely accepted and used, why doing things more complicated than needed?

Yes, as it was recently seen with the heartbleed vulnerability, many things are not really as reliable as expected, but who guarantees that MAC implementation is free of glitches as well?

Another point is, as you mentioned, exchange of symmetric secrets. In absence of absolutely reliable secondary channel it may be tricky. And trusting a client may also be an issue.