Actually, it is easier to fix the flaw than it is to find them. Finding flaws is generally the hard part.
Speaking as a programmer, that is true *sometimes* and false *much more often*. Quite often, flaws can be triggered by essentially random happenstance. Unfortunately, unless you do like Microsoft *used* to do, and only patch for that particular breed of input (anybody remember the 'ping of death'?), you have to do quite a bit of analysis to determine what other inputs might produce the same (or similar) effect.
When the Microsoft WMF flaw hit right after patch Tuesday(around 1/1/2006), MS fans raved that there was no way MS could be expected to rush out a patch. In the end, MS did rush out a patch about 10 days later. And it turned out the datestamp on the new files was one day after the initial discovery. This was in a complex part of Windows (GDI API) that actually had the possibility of breaking code. But since a big bug is a big bug, there is actually very little chance of regression problems. In the case of this iPhone bug(which appears to just be a buffer overflow), the chances are near zero. If it is a control-message bug, then it becomes similar to the Windows WMF flaw, and you block out what is presumably 'undocumented' functionality.
That's actually a particularly bad example of Microsoft fixing something quickly. After all, the day after the bug was announced publicly (which was, IIRC, 2-3 months after MS had been notified), a group of benevolent hackers managed to edit the binary DLLs and produce the exact same fix that took Microsoft all that time to manage *with the code*. How long did it take those hackers? Less than one day. How long did it take the WINE folks who had implemented the WMF-related routines so thoroughly that it too was effected by the bug? One day.
Yes, Microsoft had to do a lot more regression testing than those other groups, but Microsoft didn't fix the bug in 1 day. They fixed the bug in about 60-90. Remember, they had a head-start.
When guys who have never seen the source code can edit your binary DLL files to produce a fix faster than you can manage it with the source code (and provide the same fix you did rather than just a workaround), you've taken too long.
Now, I'm making no claims about whether Apple has been lax here or not. I don't have sufficient information to make that call at this point, but given that this bug (or similar ones) seem to affect nearly every GSM phone out there, I suspect that what we actually have is a hole in the spec, where a particular breed of input was never even considered, so checks and measures weren't designed to handle them. That would be an indication of a flaw in the SMS spec, and requires quite a bit of consistency checking with third-party implementations to ensure that you don't break something else somewhere on the network.
Edit: More information found...
http://www.nzherald.co.nz/technology/news/article.cfm?c_id=5&objectid=10587816&pnum=0
It appears that this may actually not be *solely* an issue with the iPhone OS. Delay could potentially be partially AT&T's fault.
Of course, it could also just be that Apple thought they'd have iPhone OS 3.1 out already. (Assuming it is fixed in there.)