I'm confused by this claim. Apple has an ARM64 device shipped to millions of people since September 2013.
It appears to me that they kept their compiler improvements a secret for an additional six months after the public release of a product using them, and so the fact that it's only taken an additional couple months to complete the contribution doesn't really strike me as fast.
Merging two compiler backends, despite both targeting the same architecture, is not a day in the park.
LLVM gives you several opportunities to make decisions on how lowering from LLVM IR to machine code will occur, it is not likely that both backends would have been able to handle the same sets of preconditions for each other.
A very obvious example to consider: relocations.
Relocations are tied very closely to the final object file format. I doubt Apple's ARM64 backend had any provisions to deal with the ELF relocations in the psABI and I similarly doubt that the AArch64 backend had any understanding on what kind of relocations were available to it if it were to target Mach-O.
I was under the impression that Sony pushed upstream a lot of the improvements they made to clang/llvm, but they had to wait until the PS4 was announced to do so.
Aside: ARMv8 has made the messy ARM terminology even worse! Quick summary:
ARMv8 (version 8 of the ARM architecture) has two execution states. AARCH64 is the 64-bit mode and AARCH32 is the 32-bit mode. These two modes use two different instruction sets, A64 and A32 respectively (and T32 which is Thumb). A32 is (sort of) compatible with ARMv7 (which is the archiecture version introduced with the Cortex cores).
You will see A64 erroneously used to refer to AARCH64 and ARMv8. You will see AARCH32 erroneously used to refer to ARMv7. You will probably find errors in this post. ARM64 (which is what Linux calls it) seems to just mean "that whole 64 bit malarkey".
And finally, the ARMv8 cores are the Cortex-A53 and -A57 (all the ARMv7 cores are Cortex-An where n is a single digit).
However many arguments there are for the value of standards bodies, this is an impressive example of what happens when stewardship of a technology is in the hands of a company with a monetary incentivize to keep quality high and get changes agreed-upon quickly.
If you're interesting in LLVM/Clang news and developments, you may be interested to subscribe to my http://llvmweekly.org (and/or follow @llvmweekly)