Actually multi-threading & 64-bit support are quite independent features used to solve different problems.
The above is most likely a symptom of lag induced by executing on a single CPU thread, not lack of address space in a 32-bit process, and would not be helped that much by 64-bit support. It would be helped though if Sins was multi-threaded - when run on a machine with multiple CPU cores. There may be a small speed advantage to using 64-bit as C/C++ compilers can generate more efficient code, eg by using more registers and a modern instruction set. But the gain would be nowhere near the advantage of using all CPU cores.
The limitation is actually not so much with Sins but with the DirectX 9 Windows API that Sins makes use of, which at the time (Win XP era), only allowed graphics to be rendered on one thread. That probably didn't seem a big deal, at the time Sins was written, as not many machines had multiple CPU cores.
However, Sins would have to use a more modern graphics API (eg DirectX 11, Mantle/Vulkan) before it could make the best use of multiple threads.
Also changing single threaded apps, like Sins, isn't really feasible, hence why the community, including myself, would welcome a new multi-threaded Sins 2.
Naturally it would be compiled for 64-bit as I doubt any new machine with a half-decent graphics card still has a 32-bit processor.
The main advantage of compiling for 64-bit is the amount of memory a process can allocate. For games that mainly means nicely detailed models, eg higher poly meshes and higher resolution textures and the capacity to store more units, ie no need at all for LAA.
The combination of multi-threading and 64-bit would improve overall scalability, ie the address space to store lots of units and the multiple threads required to smoothly animate them all.
So feel free to show support for a second incarnation of this much loved game, but be patient. I'd rather the Dev's take their time and do Sins 2 right rather than rush out something too soon. Here's hoping ...
