Relying on mobile as a second factor is somewhat haphazard anyway - there are increasing numbers of people relying on mobiles as primary internet access devices (especially in countries with limited wired infrastructure), so an app on a phone, an SMS, or an email can end up on the same device the attacker is using. This already causes problems - try making a payment with Paypal's mobile app if you have 2FA enabled, and it won't let you, since it attempts to protect against this kind of attack. They don't seem to have a good solution to it though.
There are obvious mitigation strategies to the attack in the paper referenced: phones could restrict installation from browsers (e.g. require a code displayed on the browser to be entered on the phone by hand, or disable the function by default, in a similar way to Bluetooth pairing methods, so the phone user needs to be actively looking for installation attempts for them to work), the app stores could be more proactive in detecting SMS reading functions, or the 2FA receiving pages could prompt for extra verification details (e.g. require the site password to be entered, which would add obstacles to session stealing attacks, or prompt for specific characters of the sent code, making human interaction easier than automated entry).
For most accounts, though, it's probably a low risk. If you use a strong password for your app store account, it should be hard for an attacker to trigger such a background load, and you should always pay attention to new applications being installed on your device. There are always applications that slip through any monitoring system, so the problem would appear to be the blind trust placed by the phone in the app store automated install process - a case of usability with a security downside.