Ever since the iPhone came out, there's been a mildly vocal minority who want Apple and Adobe to work together to put Flash on the phone. John Gruber has already nicely summed up some of the technical and legal reasons why it won't happen; what we should try to understand is why there's a demand for it in the first place.
There are very few times when I'm on MobileSafari and find that I can't do a certain task. Sometimes it's a case of just wanting to be on a full computer — writing a blog post, for example — but I still could get it done if I needed to. When I do legitimately run into a roadblock on my phone in regard to Flash, well, it's important to determine why I'm hitting that roadblock to begin with.
Flash is used online in three broad forms: advertising, rich content experiences, and video. I think in virtually all instances the general consumer could care less about the first two. 3G is going to be fast, but not fast enough where you wouldn't notice the extra KB loading an ad or two, or loading up some design shop's Flash-based design. As Gruber mentioned on The Talk Show, a lot of the speed difference on the iPhone is processor-based; even over Wi-Fi the iPhone does take noticeably longer to render a page than on your desktop (although it does perform extremely well in comparison to other phone s' render times over Wi-Fi). It's not a question of speed, it's a question of how fast of a processor you can really cram into a phone without compromising battery life or physical size. I can't imagine adding another layer on top of that — a Flash engine — would be anything but bad for rendering times. Even if the processing hit can be managed, the additional overhead will still have some type of impact; iPhone, for example, keeps previous "tabs" open on the phone with the content rendered until MobileSafari maxes out its share of memory. At that point it slowly garbage collects old tabs one by one until it reaches a more appropriate memory usage. That's why you can have five tabs open, but when you hit a larger page and then try to return to a previous tab you'll find that you'll have to make your request over again.
That brings us to the last form of Flash online: video content. This is the stickler, and I suspect this is the area that most people are clamoring for. I admit, it's a bit of a pain in the ass to see a link on reddit or via email or whatever, only to click on it and see that you can't run it because it's an embedded YouTube video or a different video service all together. If it's the former, there are ways to get around it. The problem is that, while iPhone's YouTube player is actually pretty slick, if the code is embedded on a page outside of YouTube.com, the YouTube app can't pick up on that. The easy option is to get a bookmarklet like iTransmogrify, which uses JavaScript to parse the current page's DOM looking for YouTube embed code. If it finds it, it writes a floating div into the page that lets you tap straight into the YouTube app. Given the current rumors surrounding iPhone 2.0, it sounds like this type of functionality will be added come July so we won't need to deal with workarounds.
We have a decent YouTube solution, and for some people that might be enough. YouTube has a commanding lead in online video. But there are still times where you might want to see a video on Vimeo, for example. How do we tackle that problem? There isn't a Vimeo app (although I suspect this might change as we move into the post-2.0 state: perhaps more and more site-specific apps will start coming out free of charge). The problem is that from the looks of it, the SDK doesn't give any hooks into MobileSafari. I believe YouTube's app is able to work with iTransmogrify through some sort of youtube:// protocol that it calls, similar to Google Maps integration on the phone. It remains to be seen whether a developer could add a vimeo:// handler, although it sounds like this isn't the case.
It leads to a lackluster state of affairs, then. Even if someone were to build a MobileFlash and got around the legal issues of doing so, there's really just not a way to hook into the SDK to make it useful. I don't think the way to build it is to mimic the desktop experience: you just don't want to have to suffer through performance degradation just to load up an ad or to play around with Flash navigation that isn't build for finger-based input anyway. Even on-page video would be frustrating: given screen real estate, you'd have to manually expand the content so that you could watch it close to full-screen rather than trying to squint to make it out on a zoomed-out page. The solution is to either build a separate Flash app similar to YouTube's app or MobileQuickTime: a "click to view" link that transports you out of MobileSafari for full-screen viewing and controlling.
The SDK prohibits code that runs code, and there currently isn't a way to link MobileSafari to new apps, so it looks like we're stuck. It does look like there's a reason to want Flash on the iPhone, it's just that it's usually outweighed by the many more situations when you don't want to have to waste time loading ads, for example. Given the limitations of the SDK, I don't think we're approaching a time where MobileFlash is feasible. Given the limited reasons of why someone would want Flash on the iPhone, I don't think we're approaching a time where Apple feels that the limitations of the SDK should be lifted.