Interpreter threads seem to be closer to a lightweight process model (like Erlang), with limited shared memory IPC (unlike Erlang). They avoid most of the hazards of the underlying C threading model, at the cost of strongly isolating the threads. If I understand correctly, interpreter threads were originally introduced to support emulating fork on Windows, where there is no fork system call and starting a process is ridiculously expensive.

Threads in general have been a big marketing lie. The gains from multi-processing are often lost (and then some) in locking and mutual-exclusion overhead. I seem to remember reading of multiple attempts to rewrite the X Window System graphics server to use threads; they all failed when the multi-threaded versions turned out to be significantly slower than the original select-based code, even on multiprocessor hardware.