It's even more puzzling when we're talking about background data upload when the potential SSL handshake latency isn't going to pose any UX issue. This has boggled my mind for years actually. Why?
I can easily see smaller developers deciding to go for HTTP instead of HTTPS just to avoid dealing with all that bureaucracy.
There's one step of the submission process that asks about the use of cryptography and I've always picked the option that doesn't require submitting any additional paperwork - never had problems. I forgot the exact wording but I always worked under the assumption that SSL isn't what Apple is talking about when they ask about the use of cryptography.
If developers had to file paperwork with various governments just to use SSL in their app, then simply using one of the many third party APIs that require SSL (e.g. the Foursquare API) or even just embedding a web browser view that may end up loading an https URL would require the developer to go through the paperwork route to get their app approved. That wouldn't make sense.
There are even handy tutorials that other devs have compiled to help the rest of us through it, like http://blog.theanimail.com/iphone-encryption-export-complian... and http://zetetic.net/blog/2009/8/3/mass-market-encryption-ccat....
To this day, LinkedIn's web site still doesn't appear to use SSL by default (I haven't used the mobile app in years after not only snooping my own proxy to see that everything was in clear-text but also finding that it recommended bunches of contacts it shouldn't have; Support was not cooperative in helping me determine why/how they acquired that contact info or how to stop it--I assume the culprit was a surreptitious Address Book siphon). Clear-text access to the Web site is a fantastic feature for employers who want to know what their employees are up to on LinkedIn all day, among other things...I would love to know why they still haven't implemented site-wide SSL by default.