It depends upon what trust you have in the cloud. If you don't trust the cloud provider, a malicious model (treating the cloud as malicious) might make sense.
The so-called "semi-honest" threat model almost never makes sense in practice. It amounts to assuming that someone is malicious ... but not malicious enough that they'll deliberately, actively try to subvert your security. That's a very weird kind of assumption to make. The "semi-honest" threat model is basically a theoretical construct that has no good practical motivation in its own right. There may be a few special places where the "semi-honest" threat model might make sense in practice. However, my view is that the "semi-honest" threat model is inappropriate for most practical systems engineering purposes.
Please understand: if you're using (say) Amazon EC2 for your cloud provider services, usually the threat to worry about isn't that Amazon is deliberately out to get you. Rather, the more realistic threat is that Amazon gets penetrated by some malicious third party and the attacker is then out to get you. Or, that an Amazon insider (e.g., one of Amazon's sysadmins) tries to get you. Or, that Amazon has an inadvertent security breach that exposes your data. For conciseness, we often summarize those by saying "Amazon is untrusted" or "the cloud is untrusted", but that doesn't mean that our primary concern is about Amazon the company itself.
Conversely, just because I'm pretty sure that Amazon the company isn't out to get me doesn't mean that it's safe to treat the cloud as trusted. I still have to worry about whether there might be an inadvertent vulnerability or breach in Amazon's systems that lets the attacker take control of Amazon EC2 and thereby attack me. If I'm worried about that sort of thing, I need a protocol that essentially treats the cloud provider as untrusted.
