First, as I said the reason for the fork/exec in the shell is that there is no other way. Now I think I see your question... why doesn't the kernel has a spawn_process() system call to provide an alternative to fork/exec. Since I did not design the kernel, I don't know the definitive answer. But I can speculate. First both fork() and exec() are needed. For example an ftp server must fork a copy of itself to handle each new connection. Threads now provide an alternate, but threads are new and an OS without a fork() would be missing an important capability. exec is even more fundamental and almost all OS's will have an exec capability. For example, a login program will exec a shell. Another separate spawn_process() system call would expand the kernel. Originally unix was run on systems with only a few kilobytes of memory. The added cost of a separate system call could not be tolerated. It does seem like a waste to copy an entire process and then a few instructions later invoke exec to replace it. This bothered everyone a little bit and as unix evolved, the addition of shell scripts hightened the concern since unix was forking more often. Meanwhile memory sizes were increasing. Also a version of unix was being developed at Berkeley and the Berkeley guys loved shoving stuff into the kernel. They added vfork(). With vfork, a process pretends to copy itself. The parent hangs and the child runs. When the child execs, the parent is free to run. No more copying those large data regions. vfork() tends to still be available, but fork() was souped up. These days a fork() does not copy the process. Both processes simply more forward using the same image. If either process wants to change something, that page is copied. This is called copy-on-write. Some architectures cannot handle this so they use copy-on-access instead which is almost as good. And neither process stalls as with vfork(). So fork() can now out-perform vfork() in many cases. This eliminates most of the overhead you may be perceiving with fork/exec.

Again these days, most stuff will be shared by the two processes so very little new stuff pops into existence at fork time. exec overlays these structures that define the process. But you may be surprised here. Suppose that we have a case of a "login" doing a fork/exec for ksh. There probably is already a ksh running somewhere on the system. We simply point to its text segment. If this is the first ksh, the structures that define the process are empty. As it runs, the pages it needs will not be there. So a page fault will occur and the page will be loaded. So ksh will page fault its way into core and only the parts of the program actually used will come in. In each case, ksh will probably be using shared libraries which are already in core. So not that much happens during an exec() either. Entire processes are never copied nor loaded. Both fork and exec are very fast now.

To be complete, Linux has clone() and clone2() system calls which are a bit like vfork() was. But these clone calls are intended for internal use only and then only to implement threads.