Forking predates threads. It's also makes more sense as a system call, since a library writer can implement spawn() in terms of fork() and exec() but not vice versa.
It's also still a good model when you want to run N copies of the same code concurrently, since the processes are isolated from each other, making it easier to reason about correctness. There are some wrinkles (primarily due to inherited global state such as filehandles), but they're reasonably well understood (by Unix+C programmers).
If you need significant shared state between concurrent paths of execution in the same code, then threads are probably easier.
Maybe clearer than it should be then :) You would still need something like fork, even if unix would have had threads from day 1. It's just that we wouldn't have been using fork+communication to simulate multi-threading in those cases where multi-threading are more appropriate.
It's also still a good model when you want to run N copies of the same code concurrently, since the processes are isolated from each other, making it easier to reason about correctness. There are some wrinkles (primarily due to inherited global state such as filehandles), but they're reasonably well understood (by Unix+C programmers).
If you need significant shared state between concurrent paths of execution in the same code, then threads are probably easier.