Having a computer program "multicore" isn't a simple tick-in-a-box thing, except on marketing Powerpoints.
Actually multithreading a part of code varies between "easy" and "completely impossible". The actual improvement in processing time varies from linear improvement (i.e., 4 threads run in 1/4th time), to no improvement at all, to actually a decrease in performance (threads are always waiting for synchronization, there is only overhead).
Most often, having a program "multithreaded" simply means that some of the different parts of the programs will run in parallel with increased performance.
It does not mean that any single feature, such as the length tuning, would properly parallellize. It's a hard problem and a lot of work often spent better elsewhere than trying to parallelize everything. If everything's working as it should, maybe it parallels well, a rendering function may use another core, and length tuning another, but if the length tuning becomes the bottleneck, and stuck in evaluating some rules in a loop for example, then it doesn't help much. The right way is to see what stalls the algorithm and fix it, not expect great improvement by multithreading.
Seeing one core at 100%, others near zero is a tell-tale sign that some specific part of the algorithm which just runs a processing loop and can't be / wasn't parallelized is stalling.
"Altium is multithreaded" is a completely meaningless claim as is. No practical program runs every feature succesfully parallelized, since it's impossible to do so. Most of the algorithms in the backend are single, blocking operations. Having some of them run in parallel is a great achievement already.