Snuggling up to XCode and Obj-C because Apple pushes it is no better (or worse) than snuggling up to Flash because you are used to it.

Well said.

In the end, Adobe has decided to make Flash into a programming language for certain types of media, and since Apple won’t allow their bloated runtime onto the phone, they have decided a newer optimized backend is in order.

Good for Adobe. Everything they do turns to Bloatware in short order. I’m glad Apple stood up to them.

But more important, this is simply another programming language on the phone. The market is just now getting to the size where alternative languages and/or compilers should start appearing.

They will all have to put out something that will run in Apple’s harness, but it doesn’t have to look exactly like the horse Apple rode in on.

Yes, mobile phones are constrained devices, so more and earlier optimization is required, but any app that utilizes Cocoa Touch widgets — virtually all non-games — does not tweak them “down to the last sub-pixel,” and it is laughable to assert otherwise.

Performance and tool choice are not an on/off thing. Yes, using Obj-C will likely allow more control over low-level stuff than using Flash. If your app does not require that control, so what?

Similarly, I would expect somebody who really needs performance to chuck Apple’s UIKit and the runtime dynamism of Obj-C wrappers as much as possible and stick to straight C.

Does that make Obj-C ill-suited for iPhone game development? Of course not – the “so what” applies here too. You pick the toolchain that gives you the best balance for your project. Obj-C has a HUGE sweet spot for iPhone (and Mac) development, but is not — and should not be, for any competent developer — the only choice in town. Flash and Monotouch are not ill-suited to iPhone development; they simply occupy a different place on the continuum.