Al Viro had sent in a late pull request for ExportFS to fix 32-bit NFSD handling of 64-bit inode numbers. Linus rejected the pull on the grounds that he wanted to ship Linux 3.12 on Sunday and the fix for a problem that has always existed.
In a follow-up response, Linus went on to reaffirm the general feeling amongst most developers: newer hardware is more important (in this case, 64-bit support) than old (32-bit). Linus had said, "32-bit is less important."
Yeah, I think the circumstances have changed. 32-bit is less important, and iget() is much less critical than it used to be (all *normal* inode lookups are through the direct dentry pointer).
Sure, ARM is a few years away from 64-bit being common, but it's happening. And I suspect even 32-bit ARM doesn't have the annoying issues that x86-32 had with 64-bit values (namely using up a lot of the register space).
So unless there's something hidden that makes it really nasty, I do suspect that a "u64 i_ino" would just be the right thing to do. Rather than adding workarounds for our current odd situation on 32-bit kernels (and just wasting time on 64-bit kernels).
At least now most Linux distribution vendors are onto promoting their x86_64 images, albeit it took Ubuntu until recently to do so.