That paper strikes me as seriously over the top.  It says "Writing multi-threaded scsh programs is easiest when threads behave mostly like processes", and that's true, but the easiest way to make them behave like processes is for them to *be* processes.

Otherwise, look at all the things you have to virtualize:  not just the umask and working directory, but the euid and egid, the environment variables, and the effects of fork(): that's as far as the paper goes.  Not mentioned but also per-process are the process root directory, the command line (if it's mutable), the array of file descriptors, the process security context, the process resource limits like ulimit, the mount points, the signal handlers, ....  In the end, though, the process executable cannot be virtualized: you can't have each thread run its own executable while keeping the process intact!  (When a thread calls exec() all other threads are destroyed.)

So why do threads?  The paper also says: "Threads share state. This enables inter-thread communication by explicitly providing several threads access to shared state by lexical binding."  But if there's one thing we've hopefully learned since 2002, it's that shared global state outside a database or something else carefully designed to handle it is a Really Bad Idea.