You can tweak it to run on whatever you want indeed, but is it still MQTT, if it’s not inter-operable with off-the-shelf MQTT-compliant software?
If we go back to “what problems MQTT solves?”, it’s a protocol that lets you choose what data subset is sent to which server, and where the data producer notifies the consumer about monitored value changes without need for an explicit poll from the monitoring app [1].
The central no-polling feature doesn’t work if the TCP connection isn’t kept open, and it can be especially tricky to hack around if there’s a NAT between the client and the server (as is frequently the case on wireless networks).
Security is left to TLS: that’s a one-off bandwidth and computation cost if you keep the connection open, so it’s OK; but if you need to reconnect, i.e. pay the TCP handshake overhead + TLS handshake overhead every time the device uploads data and polls for commands, you’ll typically spend most of your bandwidth budget on overheads. DTLS fares better, as it runs over UDP and there’s no such thing as a “UDP connection life-cycle”; but putting MQTT over DTLS would be a rather extensive hack, and the result wouldn’t be compatible with anything else.
The bottom line is, since MQTT doesn’t specify its data serialization protocol (although JSON seems the most frequent choice), if your subscription model is “push everything collected to the same unique server”, and you need to disconnect between uploads, you’re left with something that doesn’t perform better than HTTP.
OTOH, putting an MQTT broker on the device, to consolidate data sent locally by a swarm of IoT sensors, then send that back through a big-dumb-pipe to a server such as AirVantage’s, where it’s consolidated across sites, and accessible through HTTP/REST APIs for regular web developers, makes a lot of sense.
[1] Well I’m lying by omission: it also allows you to claim, albeit quite deceptively, that you use an “IoT protocol”, whatever that means out of press rooms.