This is not necessarily a bad thing people.

First off, code that can support dual/hyperthreaded procs (called multi-threaded code) is fundamentally more error prone and complex to write. You would expect more crashes and hangs in such code than in normal single-threaded code (even assuming the programmers are being careful)
Second, the rendering process isn't necessarily something that lends itself to a multi-threaded app. To take advantage of this, you need something where you can take advantage of doing two unrelated things at the same time. Rendering shadow maps might gain a benefit here (and you could render multiple frames of an animation, since they don't depend on each other), but at the cost of essentially running two copies of Poser at the same time. The really bad part is that you'd double your RAM consumption (in the worst case). If you have tons of RAM, you might net a speed increase, but if not, then you'll just get slowed down on greater disk access.
Third and finally, If you have a dual proc/multithreaded system and Poser only uses one of the procs (or virtual procs on a MT system), then the other proc is available to run your web browser, virus checker, e-mail, etc. without an impact to your render times!. That was the major reason I just upgraded to an MT processor, was so I could keep using my machine while I was rendering (before, the machine would get so bogged down on a render I'd have to go do something else in the meantime).

Dual Procs are not strictly for speeding up single apps. They are much better at guaranteeing that your machine stays responsive and usable while you're doing something complex.