I'm not entirely sure I agree with you.

  1.  Cell phones may cross over the 2 GB boundary soon,
      but ARM can already comfortably address terabytes
      of RAM through segments, as mbell notes.  At worst,
      we're limiting individual applications to under 
      2 GB of RAM--not the end of the world.
  2.  While being able to address 64 bits at once is useful 
      for some computing tasks, *most* of those (scientific 
      computing being a biggie, but also some parts of video 
      editing or sound mixing) just aren't ones people 
      currently do on a cell phone.  They likely will  
      eventually, but the hold-up there is as much about 
      getting the data onto the phone in the first place as 
      actually doing anything significant with it.
  3.  Adding 64-bit wide paths adds a *lot* of silicon for  
      something that would currently not get used at all, 
      and in the future won't get used much for quite some 
      time.  More silicon means a shorter battery life and 
      more heat--not exactly what you want in a cell phone.
      Look at how much effort ARM's going to in big.LITTLE
      just to let them go superscalar, let alone 64-bit.
  4.  Finally, the on case where you might get good
      benefit--games--are better served through GPUs and 
      ARM's existing NEON instructions, which already work 
      on I believe 128-bit-wide values.

So those are all the reasons why I don't see the lack of 64-bit ARMs right now as a real problem. And, indeed, if ARM were only getting used in cell phones, I wouldn't honestly see a pressing need to go to 64-bit chips, period.

But ARM wants to move into servers, and there, the situation's obviously very different. 64-bits is a no-brainer for any moderately sized database, and that's where I suspect ARM really needs this ISA. But those will take a few years to build and gain acceptance, anyway; they've got time.