When communicating with a web server, you may be interested in:
Guaranteeing that you're actually communicating with the server, not somebody who pretends to be that server.
Encrypting your communications. It's not of the business of your ISP what you store to Amazon S3 or what text messages you send through Twilio.
Ensuring your request or the response from the server weren't tampered, i.e. what is received is exactly what was sent: no change of information, nothing appended to it, and nothing removed from it.
Avoiding replay attacks, i.e. when somebody records your request, and performs it again later on.
HMAC solves only one of those needs, more exactly the third one, but does nothing to address the other three. Instead, HTTPS addresses all four. There are simply no valid cases where you would be concerned about tampering, but wouldn't care at all who are you communicating with, who's listening in the middle and how many times the requests you do are repeated.
Why not combining HTTPS and HMAC? The thing is, nothing is free. If you add layers for the sake of security, you should really be sure they bring a benefit which outweighs the cost of extra complexity, extra development, extra testing, extra debugging. Especially in terms of security, your code should be as simple as possible.
So why, you may ask, HMACs exist in the first place? Well, there are other means of communication where they make sense, such as communication between two electronic devices which simply don't have the computing power to use TLS and no ability to keep track of certificates.