Here is a quick highlight of the typical workflows suitable for a particular protocol, and some rationale.
Apart from being light weight, MQTT offers publish/subscribe semantics (on the same socket) which makes it easier to program on the IoT device side. IoT cloud service providers like AWS IoT and Evrythng and others offer MQTT based device connectivity.
It requires a message broker (server) for its functioning. This makes it a good option for remote/cloud communication, since the cloud server acts as the message broker between the IoT device and other app/services.
This also makes it NOT a great option for local network communication between devices, because it requires the end-user to deploy an additional broker in her system.
**REST API over HTTP/HTTPS/Websockets:**
As is already known, this is a great option for apps <-> cloud communication. Abundant support and frameworks are available for handling all the common use cases.
This is also a good option for IoT device (server) <-> app (client) communication in the local network. Again the reason is that this model is abundantly supported in the app ecosystem. And most Wi-Fi enabled IoT devices already support a web server.
This can (and is) also be used for device <-> cloud communication. So essentially the IoT device acts as a Web Client. The one problem that you have to work around is that HTTP is a challenge-response protocol. So the device will either have to keep polling the server for new updates, or use long polling, or use websocket.
CoAP runs on UDP and thus can be run on extremely resource constrained environments. It offers semantics parallel to HTTP for the most part.
It is a good mechanism for local network communication, particularly when their is an ecosystem of other CoAP devices.