At a small scale, i.e, with just a few sensors where they will have plenty of power (CPU and electrical), or say if the communication cost is low then you really don't need to use MQTT. But at larger scales, i.e, with many sensors where the power (CPU/electricity) is limited for them or let's say when the cost of communication is very high, then these IoT protocols like MQTT will make a difference by offering you all needed advantages. Also, you could implement MQTT with just a simple embedded CPU, whereas HTTP would be more complex to implement.
And, yes! You'll definitely save a considerable amount of battery power with MQTT compared to the 3G network as you'd have less protocol overhead from publishing MQTT data over a persisting TCP connection from MQTT client to broker than you'd have for every REST POST that usually needs you to establish an SSL connection, post data using the elaborate HTTP, and then, delete the SSL connection. And, since MQTT connection is inherently bidirectional, you'll natively have the ability to send commands to your sensors. But, for doing the same using REST/HTTP, you'll have to configure your server for long polling first.
Check out this comparison of long-polling HTTPS vs MQTT over SSL:
http://stephendnicholas.com/posts/power-profiling-mqtt-vs-https.
It says here that 4.1% battery power was saved per day using MQTT in contrast to the slow-polling HTTPS. That means you do save significant battery energy. And, using MQTT, you'd also be able to send very small messages, i.e, just a few bytes of binary data, with low overhead. Whereas, using REST/HTTP wraps a lot of HTTP protocol around the data, with much higher overhead. Also, if you have many devices, the overhead bytes will add up, resulting in a lot more data to be sent, costing you more money. So, for large scales, using compact protocols like MQTT and designing your data transfers carefully will save you a lot of money.
When using MQTT, your app usually has a persistent subscription to topics and gets automatically notified of any updates. Now, to give you a summary every minute, your app saves all updates to, say, a database and report from that database. It is usually the same database where all your data is saved in and you can subscribe to wildcard topics, which means you design your topics to make sure that your app subscribes to only the required set of sensors and the broker sends data from all connected devices without needing your app to poll the sensors individually.
