A single IoT device sending occasional data over HTTP works fine, and for a small prototype with a handful of devices, there's no real reason to reach for anything else. The problems show up specifically at scale, once the device count grows into the hundreds or thousands.
HTTP is a request-response protocol built around one client asking one server for one thing at a time. Every telemetry update opens a new connection, sends headers that are large relative to a small sensor payload, and closes the connection again. At low device counts that overhead is invisible. At high device counts, especially on constrained cellular or low-power connections, it adds real latency and real battery cost.
MQTT was built for exactly this problem. It keeps a single persistent connection open and sends small, lightweight messages over it, with a publish-subscribe model that decouples devices from whatever is consuming their data. A device publishes to a topic without needing to know who's listening, and new consumers can subscribe without the device needing any changes at all.
MQTT's other genuine advantage for IoT specifically is its handling of unreliable networks, which describes most real-world device connectivity. Quality-of-service levels let a device choose whether a message can be safely dropped or must be guaranteed delivery, and a last-will message lets the system detect a device going offline unexpectedly rather than just silently stopping.
The realistic guidance: HTTP is fine for occasional, low-volume telemetry from a small number of devices, and for anything that's fundamentally request-response shaped, like a device checking for a firmware update. MQTT is worth the added setup once the system involves real device counts, constrained connectivity, or a genuine need to react to device state changes as they happen rather than polling for them.
