The gold linker was designed as an ELF-specific linker, with the intention of producing a more maintainable and faster linker than BFD ld (the “traditional” GNU binutils linker). As a side-effect, it is indeed able to link very large programs using less memory than BFD ld, presumably because there are fewer layers of abstraction to deal with, and because the linker’s data structures map more directly to the ELF format.
I’m not sure there’s much documentation which specifically addresses the design differences between the two linkers, and their effect on memory use. There is a very interesting series of articles on linkers by Ian Lance Taylor, the author of the various GNU linkers, which explains many of the design decisions leading up to gold. He writes that
The linker I am now working, called gold, on will be my third. It is exclusively an ELF linker. Once again, the goal is speed, in this case being faster than my second linker. That linker has been significantly slowed down over the years by adding support for ELF and for shared libraries. This support was patched in rather than being designed in.
(The second linker is BFD ld.)
The gold linker is deprecated in binutils 2.44 and will be dropped entirely at some point in the future.
The gold linker was written to make the link process considerably faster. According to the gold auther Ian Lance Taylor
At the moment gold has only one significant advantage over the existing linker: it is faster. On large C++ programs, I have measured it as running five times faster.
He is comparing gold linker performance with the traditional GNU linker. gold (unlike the GNU linker) does not use the BFD library to process object files.
The limitation of gold is that (unlike GNU linker which can process many object file types) it can only link ELF format object files.
Regarding the issues you faced with when using GNU linker, here is an interesting answer to a similar question on SO from Michael Adam:
The gold linker even found some dependency problems in our code, since it seems to be more correct than the classical one with respect to some details. See, e.g. this Samba commit.