With HTTP requests, generally each request must make a handshake with the web server which may involve several interactions. And then, the client has to request everything from the server. There are some more complex methods that seek to lower these overheads but they can be more complex to set up and typically they all require TLS encryption (e.g. HTTPS) to be configured as well which comes with its own overheads and complexity.
The final issue with HTTP(S) API's is that they are many-to-one connections (again, there are ways to reduce this but at significant added complexity). Many-to-one means that many clients all connect to the single web server directly and, in the case of Node-RED's web server, each client connection must go through that handshake each time to make the connection before being able to send or request information.
MQTT, on the other hand, was specifically designed for lightweight, high-speed interactions. Indeed, it was born out of the birth of IoT, so specifically for the use-case you have mentioned.
MQTT is a "Message Queue" and works on a submit/subscribe basis. That means that your clients interact with a "broker", the MQTT server. You can submit messages but also (over the same connection) subscribe to "topics" and be notified when the topic gets a new message.
The initial handshake is typically very lightweight and fast, much faster than the typical HTTP(S) handshake. Indeed, connections will generally stay open once made which means that clients don't need to keep reconnecting as long as there is some kind of regular interaction (sometimes referred to as ping/pong).
Another advantage of MQTT is one you mentioned. MQTT has a limited set of response messages (much more so in v5). These are able to tell the connected device, for example, whether data they sent to the broker arrived successfully. There are message settings that also help you have guaranteed messages and even ones that can be retained offline until reconnection. Also, the broker can have "retained" messages.
Another advantage is that using MQTT decouples your client devices from your data processing server. The broker is a message hub - think email for machines but a heck of a lot more efficient. Brokers can also talk to each other which can easily create interesting messaging meshes.
The potential disadvantages of MQTT are:
- Another server to set up - however, the most popular broker is Mosquitto which is crazy small and efficient. You can easily run it on even an early generation Pi along with Node-RED and other tools. Even with that configuration, it will likely handle many thousands of messages per second.
- Typically, the data you exchange with a broker is likely to be a lot smaller than you might with a web server. This is generally not an issue. Not only are IoT messages often tiny, you can easily split more complex data down into individual topics and messages.
Check out here to learn the fundamentals of MQTT, it is far better explained than I can:
Using a broker gives you a high-performance, very highly robust message hub that won't be broken or impacted by some rogue code in your compute server (Node-RED). Even if Node-RED crashes, the broker will continue working.
I should also point out something of a compromise mechanism called Web Sockets (ws). Ws initially connects over HTTP(S) and then "upgrades" to WS(S) which is a persistent connection rather like MQTT. Node-RED, the Dashboards, UIBUILDER and similar nodes use ws to ensure efficient, near real-time communications. However, you are still totally reliant on Node-RED's web server and have no fallback if that server crashes or has performance issues.
MQTT v5 has some much more complex capabilities. Thankfully, you don't have to worry about them unless you need them.