Apple's handling of read-only code pages is a departure from the convention in *nix systems, which typically do NOT support re-loading of code pages from the executable file. Instead, iPhone OS is more similar to how Microsoft Windows does things. In traditional *nix systems, there is no distinction between code and data pages in handing virtual memory - BOTH are written-out to backing store when pages are discarded, and code is never re-loaded from the original file. (One positive side-effect of this is that *nix systems are easy to hot-update, as there isn't the concern about changing an executable file while the application is running as there is under Windows.)
I believe that Unix (and Linux) systems have behaved like this for many years now. At least since the 90's. Page in code from an executable only as needed, and if there is memory pressure it can just discard a code segment, since it can access it from it's file at any time (assuming disk doesn't get pulled out, or die). It is only malloced memory that needs to get moved to swap. And with mmaped files, it can just be flushed out to the file if necessary, not to swap.
The mechanism that Unix uses to handle replacing an executable works well with how the filesystems work. You can unlink a file, and it is removed from the directory. But as long as the file remains in use (such as it is running), it remains on the hard drive. So it can be replaced, and the next time the program is run, it is the new copy run.
The 2 main reasons that the iPhone probably doesn't support paging are what is mentioned here, wearing of flash, and most likely performance. Overcommit too much, and performance goes down hill fast. And I bet that it would hurt battery life too.