MobileMe's ancestor, .Mac, had an SDK for 4 years now, although, judging from the number of applications that are actually using it, you couldn't guess that.

I think this was partly because .Mac wasn't that useful before, and because it was a chicken-and-egg problem: Developers didn't want to tie their application to a paid subscription service, and users didn't see much value in a service that only a handful of apps used.

This equation changes with the iPhone. People will want to sync data from their Desktop to their iPhone and vice-versa, the killer app being, of course, email, calendars and contacts. If a developer wants to create an iPhone application as a sidekick to his desktop application, he has to tackle sync, and MobileMe gives him a no-pain solution.

In fact, given the coming notification API, I think that MobileMe will give developers a "server in the cloud", if they don't want to implement one on their own. Example:

Imagine a "To do list" application, that can be used both on the Desktop and the iPhone. You are home, ready to leave, and you jot down a few Todos for the day on your Mac. The app pushes them up to the cloud, and a badge appears on your iPhone (3 new Todos). Editing or completing tasks on your iPhone will transparently sync back to your desktop.

I can see this happening for simple apps that only want to sync data back and forth. The example breaks down as soon as you want to add extra smarts to your iPhone application: a notification for an approaching due date. To do something like this, your server will have to issue a notification to Apple's servers to be pushed down to your iPhone. The moment you have to create your own server to support your iPhone application, the MobileMe gains break down: you might as well implement sync yourself and rid your users from a subscription.

Of course, as waffle pointed out, Snow Leopard's Calendar Server will support push notifications independently of Mobile Me, so perhaps Apple has a plan for more advanced uses. Time will tell.