This thought-provoking post on /dev/why!?! argues that backward compatibility is the root cause of the new iPhone restrictions. The argument is summed up in this quote:
I can think of incidents where Apple reverted OS changes, dumped new APIs, or was forced to committing massive engineering resources to something it did not want to do because a Must Not Break™ app vendor told them to.
There's no doubt that backward compatibility is often a tremendous anchor on technological evolution, especially at the platform level. The more you have "important" apps on your platform, the more pressure there is to consider them Must Not Break™. Let's say that one of these credit card payment options for the iPhone really takes off and gets adopted by thousands of businesses. And Apple goes on record saying "Gee, we love this payment option, look how easy it is for Joe Mainstreet to use iPad to run his small business out of his car." Could there be heated discussions when considering whether to release an OS update that breaks the payment-processing software for thousands of businesses or whether they could wait "just one more week until these guys iron out the last of the kinks"? Of course there could be.
Even worse, let's say that you've got a Must Not Break™ vendor whose product was written in, let's say, Prolog and compiled to the iPhone using PrologTouch. And they're having trouble and pointing their fingers at PrologTouch and the PrologTouch people say "Yeah, that's a known bug and we plan on addresssing it in 3 iterations. But they can workaround it by following this simple procedure..." Which is exactly how it goes (except for the part about people writing applications in Prolog). Everyone in the systems-level programming world knows that there's a lot of finger-pointing about dependencies and drama and sausage (as in, "you don't want to know what's inside") when it comes to synchronizing releases.
Apple certainly knows this as well as anyone and the idea that they want to try to change that dynamic in some way certainly makes sense. Limiting the number of dependencies between platform vendors and developers would probably diminish some of that complexity.
Nonetheless, it's foolish to do it with contract terms and it's absurd to do it in a way that outlaws good software practices such as code generation, Domain Specific Languages, and abstracted memory management (or at least type-safe memory management!). Forcing developers to use Objective C, C++, or C to develop applications means that you'll have more, not fewer, serious defects relating to resource consumption and security. Especially if you're a victim of your own success as a platform vendor and you have a lot of newcomers to your platform.
The success of the iPhone means that a lot of companies want to develop applications for it, including advertising and marketing applications and inward-facing corporate applications. A lot of those companies do not have experience with explicit memory management. As long as these new restrictive provisions stand, these companies will be forced to either stay off the iPhone platform or to develop software in a way that is unnecessarily error-prone. It's a rotten choice.