The fact is that single process versus multiprocess carries different tradeoffs with respect to memory. A single process has an advantage in the short run, in that it will consume less memory initially. However, in terms of private working set memory across multiple tabs you're simply not going to see anything like the 2x claimed in that link, given that much of the address space maps to shared pages. So, most likely the authors just weren't properly measuring memory usage per-browser.
On the flip side, a multi-process architecture has its own strong advantages for memory consumption. Any complex, long-running application is going to have to contend with memory leaks and fragmentation, which exert increasing memory pressure over the life of an active process. This gets even more painful when considering the multitude of heaps in your average browser, chrome layers written in Web technologies, and (iirc) Firefox using a non-moving, non-generational GC. Whereas a multi-process browser has a vastly cleaner solution to all of that: it simply disposes of an entire address space (including all fragments and leaks) when it's done with a rendering context.
You're overstating the impact of JS here. JS memory is allocated in large "chunks" in Firefox. This minimizes external fragmentation. When a rendering context is destroyed, all of the chunks are immediately destroyed with it; because of compartments, we know that there are no chrome JS objects interspersed with the content JS objects, so we can just destroy these large chunks. So the amount of JS-related fragmentation resulting from closing rendering contexts is minimal in practice.
Regarding chrome layers written in Web technologies, this is somewhat orthogonal, since in all browsers chrome allocations stick around for the lifetime of the browser. C++ code has no compaction story, and, unlike JS, it has no reasonable path to achieve compaction in the future.