The Kungpisdan Et al. paper you cite does make mention of battery powered devices with "low-computational capabilities" in section 2.2 "Mobile Payment – Problems and Limitations" although they do not describe exactly why they feel this is a limitation leaving the reader to infer the obvious 'the battery might go flat and make the user unhappy' or 'it's too slow'
But it seems they think it's very important as it is the whole motivation for the protocol they describe.
Modern 'smart phones' perform many many key exchanges, encryption, decryption, signing and so on all day every day. I'm not sure I see the problem.
You SHOULD NOT degrade the security of a system to save a few micro-amps of power.
Even embedded systems that are required to run for many years off a single battery sill use the best possible security. For example LoRaWAN uses authenticated AES with 128 bits keys.
Just to clarify my statement that battery conservation is "the whole motivation" for the protocol that was my opinion. They do also mention data costs and "wireless networks also have limitations on low bandwidth and poor reliability". Firstly protocols, be they security related or not, should be designed to be reliable on the principle that all networks are inherently unreliable be they on your phone or PC. So far as the cost is concerned the customer has already committed to downloading 100's of KB for the privilege of purchasing something via their smart phone so can probably sink the costs of using the existing secure payment service. The consumer is never going to know if they are using SET or SET/A+ or care.
The origional SET/A protocol was published in 1998 and at that time all of the above concerns were valid. Not so in 2015 when SET/A+ was proposed.