Hi Toddy,
Good to hear from you, I hope all is well.
 Just a few thoughts, maybe Trevor can chime in about any future plans.
Unfortunately, I cannot say why the processing power is capped. Back then, Modeler was not designed to support multi-threading and as you can imagine, this would require fundamental infrastructure changes. Modeler is also a 32-bit application, that’s why it cannot allocate more than 2GB of memory. And yes, this will result in some speed penalty on very complex models.
Nonetheless, we are regularly designing complex stadia with 20-30 arrays and often, up to ten modules each. If such a design takes an hour to run 2000 to 3000 impulse responses, that’s still state of the art today.
If you need to be even faster, then we’d recommend reducing the number of samples, e.g. by placing – say – 100 listeners at ‘representative’ locations and turning off the mapping for surfaces. That may give you an average STI result which is already representative of the entire system and will give you enough information to further iterate your design, apply EQ or leveling, etc.
What is most costly here is the ray-tracing – just like you said. But the geometry predictions are the same for all frequencies, so distributing frequency bands across cores would not help much. And Modeler’s pipeline already helps a lot in making these predictions most efficient.
Just for completeness, the number of drivers we use in speaker files must not match the number of physical drivers. E.g. for AM, we have two balloons/drivers in the speaker file, not seven. For RM, there are four sources and for SM, this number is three.
Are you really using the STIPA option (and not full STI) ? Any specific reason for that ?
 Hope this helps.
Best rgds,
Thomas