I am curious if you do this mapwide thing very often to debug game bugs. Cuz we all know the usual game renderer does a lot of culling optimizations like z buffer, occlusion. Maybe another approach is not doing this in realtime but rather generate frame by frame to do post-render analysis?
But I work in the same company as Gambiting, on the same game I think. And yes, loading a map that is the size of San Andreas in GTA5 (with more props) is expensive on memory.
You can't "load a region" in the editor, not because there is a design constraint but because you need to generate navigation meshes, collision systems, render objects etc before you "stream" them in, not to mention that "streaming" is a hack that is build for consoles and weak PCs and has to be optimised for to work reliably, you'd spend more time chasing bugs in your streaming than actual bugs you were working with.
So, you load the whole map, you generate your navigation mesh and run your collision detection, and then you can do mapwide things like "find breaks in the world" and other stuff.
In this case, yes, 64G is helpful, because a developers time, especially a tools programmers time who deals in very low level C++/ASM optimisations for AAA games' time is worth more than a studio full of 64G ram modules.