Multi-threaded coding is not trivial. Even when done by people who know what they are doing, timing dependent bugs can occur. They are difficult to fix. Having dealt with the one a few thousand case type bugs multi-treading can produce, I would prefer not to have them in my testing framework. The first fix I got appeared to work, but on further testing it was found that it had just become a one in tens of thousands bug.
The techniques to do multi-threading on multi processors are getting better with the advent of multi-processor PCs. However, it will take time before they are in wide use.
Some test suites have dependencies between tests that do not need to be explicitly stated when the tests are run in a single stream. However, on a multi-steam engine, they would need to be explicitly stated. (Where such dependencies should exist is a different question.)
From another standpoint, some things just don't need to be run in parallel. It the process runs adequately fast, it may better to focus efforts on things other than implementing multi-threading.