Ummm, not ARM and not necessarily better
ARM makes a processor core. To be more accurate, they design a reference design to a processor core which executes what has become a defacto standard, the ARM instruction set. If Intel were to take ARM seriously, it could license the ARM instruction set and replace the x86 instruction set decoder with an ARM one and they could come to market very quickly with a screaming fast Core based ARM chip. Remember that the Core processor doesn't actually run specifically an x86 instruction set, instead it translates the x86 instruction set into the internal native instruction path which is more like a RISC architecture as it is able to stack operations into a single clock so long as it doesn't require mutexing individual registers.
So, let's for the moment say that the ARM instruction set is the key point of interest in this case, not the reference design itself. After all, NVidia, Samsung and other companies are working rapidly to integrate their technologies directly into the ARM core to produce high performance versions of ARM chips even now. I'm sure that the ARM ALU will be completely replaced as the reference ALU, while power efficient is not particularly fast. Simply replacing the multiplier with an adaptive pyramid multiplier would be enough to increase execution performance of the ARM core substantially. But it would use so much silicon that it would pummel the battery life of handheld devices. Also, using a far more advanced instruction reordering architecture (such as that found in the Core series) would improve performance even further. In fact, given that the ARM instruction set has a much larger set of registers, if a compiler were to target ARM and maximize register allocation by fanning it out as much as possible, then a proper instruction reordering system could easily parallelize a much larger amount of code so long as the core itself were to implement enough arithmetic units to process the code.
I visited Apple a long time ago, during the birth of OS X, Just before the formal release of OS X 10.0. While I was there, I saw OS X running on x86, Sparc and PowerPC. The Darwin kernel is just another UNIX kernel and ports really well to any platform which GCC (or now LLVM) targets. Since Apple is the key developer on LLVM (or at least CLang), they are able to target and optimize to a new platform internally with little issue. At worse, they can fall back on the GCC back end to LLVM to generate code while they implement their optimizations. With only a little additional work, they can ignore generating architecture specific code from within XCode and use the LLVM JIT to target the local platform at runtime. As with MS CIL, this technology is no longer the half assed crap sold by Sun in Java. It is the real deal. Therefore, instead of forcing developers around the world to recompile fatter and fatter executables, they can ship a relatively streamlined LLVM IL exectuable. Thanks to the nature of OS which is based on bundles and more or less hidden/transparent subsystems (a technology which stems from OpenStep with did this on many platforms), the transition to this way of distribution would be relatively trivial. I simply would not be at all surprised if they have already done this, but I haven't checked.
Also, let's not make the mistake of trying to differentiate OS X from iOS on a technical level. It would be better to look at iOS as OS X but with a different "shell". iOS and OS X share the exact same Darwin (Mach) Kernel. They share most of the exact same Cocoa (NS) system APIs. They share almost the exact same additional frameworks such as QuicktimeKit, WebKit, CoreAudio, etc... they both support OpenGL (though limited to ES to support older iPhones/iPods on iOS). They both support OpenCL (through LLVM). In fact, with the exception of the system shell and the application packaging system, the two platforms use virtually identical code on every level.
So, so long as iOS runs on ARM with optimized drivers for the A5 support hardware, the only thing which really needed to be optimized for A5 would be the system shell. The system shell however is nothing more than an application itself. It almost certainly doesn't use any assembly language native to x86 or PowerPC. So, an LLVM IL compiled version of it should in theory run entirely unmodified on the A5 (or any other Darwin supported platform) unchanged.
The only issue Apple will need to deal with at this point is likely to implement Rosetta Stone again, this could prove problematic as this time instead of translating the PowerPC instruction set, it would need to translate the x86 instruction set which Intel make take issue with. While doing it should be really easy this time around as there are no endian related issues and therefore translating code from x86 to ARM will be trivial (though with major performance issues regarding unaligned memory accesses which x86 excels at), there almost certainly will be horrible licensing issues involved. Therefore Apple might instead of for an alternative method which is to simply say "Ask your software vendor to recompile their application using the latest version of XCode", and the problem will be solved.
Then the only problem is with software shipped from vendors who are now defunct or who make heavily use of x86 assembly language for optimization.
Let's address battery usage really quick. Battery usage is far less about the instruction set and far more about how each instruction is implemented and how the operating system handles power management. OS X already has fantastic power management, but desktop applications aren't power management aware and therefore often choose to use more resources than are "battery device friendly". An instruction implemented using 5 million transistors uses far less power than the same instruction implemented in 50 million transistors. But the 50 million transistor implementation might be 20 or even 100 times as fast when used. This is particularly the case with multiple path single clock dividers which employ tremendous gate depths as opposed to iterative dividers which can often take hundreds of clocks to handle simple division. Software written for handheld devices which choose to divide instead of multiply or bit shift use MUCH more battery than the alternative. Thus far, since x86 hasn't been used in a handheld environment, there hasn't been a lot of development of operating systems or software which is battery optimized. Applications generally ignore sleep events or even "Screen dimmer" events from the operating system. Intel hasn't actually been trying all this time to make a low power chip that is as limited as the ARM (with regards to things like multiplier performance), but instead has been trying to make a low power chip that runs the existing application base at acceptable speeds while using as little power as the ARM.
ARM has had the advantage that it started as platform for low power consumption (ignoring Acorn which I don't really consider the start of ARM as opposed to EPOC). It grew into a higher performance system from roots where application developers didn't actually count clock cycles since if they needed to do that, then they were coding for the wrong platform to begin with. Intel started from the other end of the spectrum. So while it hasn't been until the last 2 years (of high end ARM platforms like iPhone) that high end applications have been coming to the architecture, it's only recently that low power consumption application development has come to x86. And as a good note on this, try playing Need for Speed or another game of the type on a phone. Watch the battery drain at incredible speeds. It's not just x86 who sucks at power management.
So... in reality, ARM has absolutely nothing to do with this. Apple already has a chip and they already have OS X optimized for it. Their only struggle will be getting all the app developers to target LLVM IL. And that's less of a problem than ever since :
1) Airbook as no DVD drive, therefore software is typically installed from the internet
2) Mac OS X provides pretty much all "Apple Approved" applications through their store and "If it's not in the store, then Apple gives a shit less about it"
3) ALL Mac App Store applications are compiled using a VERY recent version of XCode
4) Using a lot of unapproved APIs for OS X will make getting an app into app store a problem.
5) It is VERY likely MOST if not all apps approved for the App store are in fact LLVM IL binaries and NOT native x86.
6) Apple probably has made a list of all applications in the app store which are in fact x86 specific and will contact the vendors to help them "upgrade" when the time comes.
7) The biggest limitation to iOS over straight OS X is OpenGL ES. But, the Samsung processor used in the 3G and 3Gs didn't support full OpenGL. The GPU in the A5 DOES. Therefore, since this would be the first Apple ARM chip used in the Apple ARM laptops, the lowest common denominator of hardware does in fact support full OpenGL and therefore IS NOT a limitation.
Now... add one more major factor to this....
A MacBook Air with ARM really only needs to be nothing more than an iPad 2 with a keyboard and trackpad. In reality, it would be 100% reasonable to suggest that Apple could in fact distribute full OS X for iPad 2 with a bluetooth keyboard and trackpad. In fact, they could even employ a proper flip-top tablet design which would run the OS X shell when the screen faces the keyboard and runs iOS shell when the screen faces away from the keyboard.
Don't think for a second that a machine has to be faster or better on battery life or anything like that. An iPad2 with keyboard and mouse would be more than enough for the casual user. As for the power user using FinalCut Pro or hardcore gamer playing Portal 2, that's a different story and ... well a different computer too.