Depends. The real cost is usually not so much that of process creation as that of context switching while running. On most OSs, it is a lot cheaper to switch threads within a process, than switch between processes.

Linux' context switching however is so fast (at least on Intel CPUs) that it can easily masquerade as threading and indeed in that kernel, "threads" are really just forked processes, with a bit of decoration to hide the separation.

So the answer really depends on what you're going to run on. If you're primarily going to run on a modern Unix, fork is usually easier to work with than threads and it has much fewer pitfalls, like paying attention to who is accessing what variables and the likes which you run into when working with threads.

On Linux, and most *nix, threads do not copy the entire process. Only a very little is copied, and the rest is shared until the page it is on changes. That is why Linux can fork() faster than windows can create a new thread. So, forking or threading is a platform dependent issue. Which is why you shouldn't use the non-portable method (threads) in a language like Perl that is usually very portable. fork() should work on all platforms.
--
Snazzy tagline here

Threads are much more efficient...It is also harder to have 2+ forks() communicate (PIPE or socket or shared memory) vs direct access to all data structures

For the love of all that is holy why do you youngsters think this stuff. Free your mind (from Win32s land) and your code will follow.

Efficiantcy: fork() + SysV shared memory is just as fast on Linux as threads. Further, you get the advantage of explicitly shared data, rather than the joys of tracking down obscure memory corruption bugs.

Easy of Use: Unix process calls + SysV shared memory API are far more simple than the POSIX thread API and more useful to learn overall.

Threads are faster for context switching than processes on old propietary unixen/winnt. That is because all those proprietary OSes were created to sell hardware. Why should they care about speeding up the common case?

Unix is an amazing API. With proper implementation it is awsomely powerful, fast, and simple. Threads are a context switching optimization/abomination.

However, perl threads could make POE really cool on multi-processor machines (re: thread per CPU to implement an explicit state machine).

while fork() does work under windows it has a number of problems. If you use a module that has XS that is not thread safe fork() emulation will probably crash your program. It also has a problem with the regular expresion engin under some circumstances.
Any one wanting to use fork() on windows should read the perlfork docs throughly.

Why is there a need for some 'threading' mechanism in Perl whereas it already has the 'fork' call?

It's hard to share data structures across a fork().

Yes, you can always get the job done using shared files, signals, pipes and such. But for some things it's just a lot more clean to pthread_mutex_lock(), change a variable, and pthread_mutex_unlock(). And select() loops are just obnoxious compared to having a separate thread or process to handle each incoming network connection (as long as you're not expecting super high performance with lots of clients)

Perl's threading works nicely - but it doesn't port to every platform perl does. This has caused me to rewrite at least one app which was originally started in perl using C. Good thing I "planned to throw one away".