Why would I use MAC over digital signature?

Performance alone is a reason to use MAC.

Consider a TLS connection. For every packet, the receiving party needs to verify that the packet wasn't modified in transit by a man-in-the-middle attacker. So for every packet, the sender needs to calculate a MAC/signature and the receiver needs to verify it. If you want, say, a 10MB/s transfer rate and an average of 10kB/packet, that means you only have a fraction of 1ms to calculate or verify the signature. That's too slow for a digital signature.

The amount of time it takes to create and verify an asymmetric signature is small enough to be a non-issue if you do it once when a connection is established, assuming you have high-end hardware such as a PC, server or smartphone (it can be an issue on embedded devices). But it doesn't work if you need to do it once per packet.

A digital signature has the advantage that it can be verified by a party that isn't able to generate a fake signature. This isn't useful in a case like a TLS connection. For TLS, the two parties set up a session key, which is a symmetric key that is generated randomly at the start of the connection. After that, the only two parties that know the key are the client and the server. If the client sees a valid MAC (that it didn't generate itself), it can only have been produced by the server, and vice versa. Similarly, once the session key has been generated, it (and not asymmetric cryptography) is used for encryption.

(Properly speaking, the same key shouldn't be used for different purposes such as MAC and encryption, even if it happens to have the right format. I simplified things a little above. The “session key” is actually some secret material from which an encryption key and a MAC key are derived — or, in some ciphersuites, a single authenticated encryption key is derived, although the AE algorithm then derives two keys internally.)

I think I might have thought up a possible answer.

With a signature the receiver (client app) can be sure that the message came from the sender (server app). But if the client app now sends something back to the server (another HTTP request posting some data) the server cannot be sure if the message really came from the same client app - any possible client could use the server's public key to create such a message.

On the other hand if they share a secret (as in HMAC), there is at least some measure of certainty that the message originated from the expected client app.

The problem with this seems to be, that a secret salt for MAC creation is not really worth much with untrustworthy clients (javascript or mobile apps) since they can always be breached.

Both HMAC and signature can be used to verify the data integrity and the authentication of messages. However signatures also provides the property of non-repudiation: given a message and its signature, you can prove that the message has indeed been written by the sender.

You might not want this property. For example, you might want to exchange messages privately with someone that you don't trust. If your messages are signed, the other party will be able to disclose a compromising message and prove that you wrote it. Using HMAC, you can still be assured of the privacy of the conversation, but the other party will not be able to prove that you wrote this compromising message because they also could have written it.