iMessage is based around APNS, which, while proprietary, doesn't require a background process on the client. This is way better than XMPP, and also doesn't try to do things that are pointless on mobile, like maintaining "presence".
This doesn't really preclude things like federation, but it's a fundamentally different approach from XMPP (though bridges are possible -- see, for example, Verbs app, also see how buggy it is, and What's App, which apparently is pulling it off quite well). But bare XMPP doesn't really work that well.
How is maintaining presence useless on mobile? I like Google Talk on android ten times better then just plain sms for this very reason. Being able to know whether your friends have service, and then being able to know whether they are actively paying attention to their phones (online/away), is crazy useful when trying to communicate.
Because there's a single thing that makes presence useful, which is the device going off or to sleep, y'know, like a desktop computer in the nineties. There aren't many people who maintain their availability by hand, as that's just a pain.
A cell phone is always on, so depending on the solution, I'm either always "online," or always "away" with some single blips of "online". Me being "online" doesn't mean I'm really paying any attention, I just took out the phone for a second while my friend was in the toilet, or anything, and now I'm gone, but will still appear as green for some time.
What's App and iMessage solves this by replacing online with read receipts, and in case of WA, "last seen online" data. Much less pretense makes it way more informative.
What he probably meant is: You don't want your mobile to be notified about presence unless you open the client and look at your roster. Or if you set a trigger to be notified if someones presence reaches a certain state. When you control the server side both is possible with XMPP. You could use privacy lists XEP-0016 for that. You'd just have to make sure that the server sends the last presence when you enable presence notification after you disabled it while the client was not in the foreground.
Also a push-notification needs something on the client to react to it, be that a running normal or a background-process. Pull needs maybe an additional background-process and generally wastes more energy, but APNS can't be that much magic.
I think the power consumption advantages of APNS come from the fact that it's built into the OS and it's multiplexed, meaning that you only ever need one persistent connection/monitoring/etc. no matter what needs to listen. If you did XMPP directly, you'd need a separate background process and connection just for that, in addition to APNS. If you had two different apps doing this, then you'd need two processes and connections, etc.
You need only one process, and, furthermore it being push means it's possible to handle it with way more resources (you don't really have to maintain anything on the client, excluding the relatively rare situations when something important changes and you have to tell about that to the server).