I think that these are indeed Apple's intentions. And I think they're the right intentions. But I think the way Apple expresses these intentions in their developer agreement has an unintended consequence.
Apple wants your app to like like this, this is good:
iPhone OS -> UIKit -> Your App
Apple doesn't want your app to look like this, very bad:
iPhone OS -> UIKit -> [Flash, QT, etc.] -> Your App
So far so good. But the unintended consequence of how Apple phrased its agreement is that the following is also forbidden:
iPhone OS -> UIKit -> Your App <- backend implementation details written in a different language
In the last case everything the user sees and interacts with is written exclusively in Objective-C. There's no middleman. But behind the scenes the Objective-C controllers delegate to code written in another programing language that's compiled and linked natively. The final executable is indistinguishable from one that was written exclusively in Objective-C. It probably would even get through Apple's approval process, though it appears to be expressly forbidden.
I explained in a previous post why you might want or need to employ such an app structure. I think such an implementation is in line with Apple's goals for the platform. It's just an uncommon corner case that gets caught in the cross fire.
Section 3.3.1 of Apple's agreement states that "only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs." Apple should clarify what directly linking means. All code is "directly linked" in the final executable. But maybe if your app links with Apple's frameworks, and also links with your own code written in another language, but there are mp dependencies between your code in the other language and Apple's high level frameworks, this would qualify as not directly linking. As long as directly linking with absolutely fundamental libraries like libc is permitted, I'd be okay with this.