I should start a video serie “fun with flags 64-bit theories”, but for now I will stick with only this short article. Here is the ironic part:
“There’s no shortage of pundits and self-described experts asserting that Apple’s shift to a 64-bit architecture is either a hoax, a pointless marketing ploy that will deliver no real benefit, or an inevitable shift that everyone will eventually follow anyway at some point, and therefore neither newsworthy nor deserving of any credit.” – for Apple Insider, Daniel Eran Dilger
The journalist then went on citing several Apple statements out of the iOS development guidelines. Considering those statements as true because aimed at developers. I guess that should be viewed as scientific proof 
You can read the full article though, it is not all bad, and better than many others I have recently read on the subject. But up to now, the most accurate comments on the new 64-bit ARM CPU for Apple’s iPhone 5s is from Anand. One of those statement is:
“When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly,” – Apple
This is slightly marketing terms. A 64-bit apps is likely to use more memory than the same 32-bit counter part, most basic data types have had their size increased. But this is true that the 32-bit stack does not need to be loaded. There is an engineering trade-off to make per app: does the gain in memory consumption when switching to 64-bit exceeds the 32-bit stack footprint? But the author does not get that point and conclude that:
“The company also outlines why it will be beneficial for third party apps to release 64-bit versions of their titles for users, even if those apps don’t in themselves score massive gains from the move to 64-bits: the key result will be lower memory use for the end user.” – for Apple Insider, Daniel Eran Dilger
Lower memory use for the end user when 3rd party apps release 64-bit apps? That would be astonishing. If all 3rd party apps were 64-bit then there is no need for 32-bit stack, but I guess this stack represents a fraction of the overall available/used memory. Apple is also recognising this drawback of 64-bit systems as they state later on:
“Because so many fundamental types have increased in size, the 64-bit version of your app uses more memory than the 32-bit version does. (…) Expect to spend more time optimizing the performance of the 64-bit version of your app.” – Apple
But this is something the journalist blatently ignore.
Note: Moving from 32-bit to 64-bit does not mean you need twice the amount of memory. Not all data types have their size doubled, and apps can be refactor to use less demanding data types.
Then the stunt on the 64-bit memory model (either LP64, LLP64 or ILP64) is also a funny one. Really who cares unless you are a developer which has to use binary data or which needs to optimise an app for memory usage? Unix decided long ago to go the LP64 way (although I do not think all Unix flavour did follow it) after evaluation (performing a trade-off) severa criterias including portability, interoperability or performance. And Windows decided to go the LL64 way, which is not bad either. And regarding performance differences between those models, it only affects the memory pressure and depending on the application this can have no impact or some performance hit. And in this regard, Microsoft choices for Windows would limit the memory pressure when directly recompiling a 32-bit apps for 64-bit.
I am not going on to talk about the journalist speculations on Android move to 64-bit with its engineering and business chalenges. I fully agree that moving to 64-bit has its challenges, and then moving the apps ecosystem is another challenge of its own. But I do not think that moving the core of Android, including Dalvik, to 64-bit is as difficult as the author is implying at least from a pure technical stand. But like him, this is my gut feeling and I have nothing to base this statement on! Hence, I won’t talk about it.
Overall, this journalist, Daniel E. Dilger, is doing a better jobs than many other before him regarding the 64-bit transition which Apple is trying to do for its mobile ecosystem. But this article is clearly biaised towards Apple and in order to be so, the journalist has taken many shortcut and wrongly understood statements made for developers (not journalists!).
Note: I love Apple since many years, I have a MacBook and an iPad (and an iPod lying somewhere). But I am pationate about Linux since almost its inception, and thus I do have an old computer and several VMs running it. I also have an Android phone since recently. The only OS which I do not stand but forced to use (only for work) is Windows. So with this context in mind, I guess my opinions above are rather objective.
Some History – The 64-bit great transition on the Desktop
You can skip this section, my point was made above, here are just some background information.
Back in 2005, I had to change my CPU (the previous one overheated). I chose an AMD Sempron 1600+ which was a 64-bit capable processor, at that time I had a wopping 1 GB SDRAM. I intalled both Ubuntu 32-bit and 64-bit and you could feel that the 64-bit version run slightly faster. The reason being mainly that programs were compile with higher optimisation set being able to use all the fancy stuff of the latest (at that time) generation of CPU plus the extra CPU registers that AMD64 architecture offered. The 32-bit edition of many Linux at that time was still compiled for 486 CPU!!! And one could gain similar small performance improvements by switching to LFS or Gentoo even in 32-bit mode. So the performance improvements are more related to better CPU optimisation than wider registers.
But after awhile I switched back to 32-bit on Ubuntu. First they started to only support Pentium class CPUs (so better 32-bit CPU optimisation), so the performance difference was not visible. And second programs started to be more memory angry, especially web pages were more complex and thus more demanding, which resulted that I hitted swap a bit faster in 64-bit than in 32-bit and this had a negative impact on performances. When this shift happened, SDRAM was no longer the norm and it was expensive to buy, so I still have (now only) 1 GB and so I took the decision to switch back to 32-bit which gives me slightly more room.
There are still some hope (for me) that my machine will still switch back to 64-bit. Linux is starting to support the x32 ABI. Basically this ABI would benefits of many of the AMD64 ISA (more registers, better system calls, etc.) but still use the same 32-bit limits as x86, so having a lower memory footprint. This has issue of its own (like the dreaded 2038 Year Unix Time bug), needs to gain more maturity and distribution.