The BlackBerry infrastructure is not a perfect cloud. It is optimized for low latency rather than large payloads. As the payload size rises, delivery can't be guaranteed. You can use RIM's cloud as a gateway to the Internet, but messaging and notification take precedence, so browsing performance and reliability are abysmal.
Businesses need a cloud that strikes a happy medium between low notification latency and high-speed data transfer. Steve Jobs pitched the original iPhone with Yahoo push mail as "BlackBerry for the rest of us," and Apple marketed its MobileMe service using a cloud logo, and at one time, Apple used the tag line "Exchange for the rest of us." iPhone's Yahoo push e-mail was DOA, perhaps a victim of Apple's romance with Google (unconsummated at the time). Still, iPhone 2.0 with MobileMe could have been a model for a RIM-like infrastructure fleshed out with a suite of services.
If MobileMe were stabilized and sold as a cloud for iPhone users, it would pass muster by consumer standards and make a fair model for a more ambitious commercial service. It does work: If you have two iPhones with active cellular data connections, messages sent between them via MobileMe are indeed pushed. There is a delay of several seconds between sending and delivery. Attachments are retrieved on their first viewing. It works out reasonably well unless you're out in the sticks where even EDGE won't reach. That's BlackBerry territory. RIM's cloud will shove the first 250 characters (or whatever the worst-case limit turns out to be) of your messages down single bar, receive-only cell data links. That's core to its design. MobileMe and iPhone aren't so obsessed with universal delivery. BlackBerry's cloud is of the slow and sure variety, while Apple's waits for a clearer shot and blasts those big, fat, desktop-generated messages to you in one stream. It's a matter of preference.
My preference would strike a balance between the two. When I'm in a cellular ghetto, I want to see some sign, at least a notice that my queue is backing up because I haven't seen a tower for the past ten minutes. Cellular Short Message Service (SMS) and cell broadcasts work even when TCP service isn't available. I want my cloud to send whatever it can, as long as my device drops it in my inbox.
One unavoidable catch of living in a cloud is that it requires proprietary client software. Standard-issue messaging and PIM clients use server polling and session-oriented protocols for broad interoperability, firewall friendliness, and cheap implementation. A cloud client has to be aware of the specific notification method used by the cloud, be able to route payload data to applications that understand how to process them, and queue outbound messages for reliable delivery over unreliable networks.
That's well outside the mandate of OS X's Mail.app, Windows' Outlook Express, open-source desktop alternatives and most smart phone/PDA mail clients. New mail appears in your garden-variety client's inbox when your client makes its 10 or 30 minute rounds, regardless of the means used to send it. You might try to play the system by setting your client's polling interval to one minute, but IT deals with this all the time. If it doesn't enforce policies on mail client polling, it can impose connection rules that keep you from abusing the server. If you don't have a push client, you're out of the cloud.