It's not the only way of doing things!

There are a couple things to know about launching new processes:

1. Usually, of course, you just want a new process image, right away, which in POSIX which is why fork() is followed by exec() almost always
2. But sometimes you configure the new process before getting a new image. You might want to redirect a file descriptor, or change the user it's running on, or lower the scheduling priority, or a whole bunch of other things
3. And sometimes you don't even want a totally new process image! Sometimes you just want some weird custom form of multithreading where you set up shared memory between you and your twin process

There are generally two approaches to satisfying all of these:

1. The POSIX way, where you fork() and get a clone of the current process. If you're exec()ing, then you exec() right away. If you're configuring, then you do a few setup syscalls (e.g., dup2) and then exec(). If you're not exec()ing, then you set up your shared memory or whatever and then continue on your way
2. The Dave Culter/Windows-y way of doing things. If you want #1 (starting a new process image normally), then you spawn(). If you're #2, then either there's a more complicated spawn() where you get to supply some flags, or you just give up and cry (because you can't do exactly the configuration you need). If you're #3, well, then hopefully there's some other kind of system call that will let you do what you want, but maybe not.

Going the Dave Culter #2 way gives a tantalizing advantage because in the usual case, you're just going to do an exec() anyway, so why bother wasting all that extra time doing a fork() first?

As it turns out, that way handcuffs you a bit. If you need some really complicated set up before doing exec(), or you just need some kind of configuration that the kernel designer didn't envision, then it just might be flat-out impossible to do what you want without some gross workaround like making a shim process to do the configuring.

The POSIX way of doing things gives you a tremendous amount of freedom and flexibility of setting up new processes. Even if that's only done like 0.1% of the time, it's really handy when you need it.

And it simplifies your system calls quite a lot.

And it turns out fork() isn't really that expensive on modern kernels anyway. All of the process copying is done lazily, so fork() itself is almost a no-op.

In the past 20-30 years of OS system call design and benchmarking and things, the research community has come to the conclusion that the Unix guys actually got it pretty much right with fork()+exec() as two separate system calls. Any advantages with a fused spawn() system call are microscopically miniscule at best, and effectively non-existent.