Needing an exact copy of the current process is an atypical use case in my experience. And the typical use case of running another binary isn't made any more elegant by fork(), it just shuffles the complexity into exec().
Here's where using fork() without an ensuing exec() is very natural ...
A server process that must reply to hundreds of network requests per second but still remain single-threaded pretty much needs fork(). The persistent parent process sets up a common configuration, accepts incoming network requests, and calls fork() (which is very fast) to do the real work for each request in a child process.
That child's work involves looking up relevant data or recording relevant data or doing a transaction that may involve only local memory, the filesystem, a DB, other processes, or other network services. The child must also reply to the network client. Doing this all in the single-threaded parent would preclude it from handling other requests and make it impossible to respond to hundreds of clients (unless the parent uses complicated asynchronous processing and the per-request work is mostly I/O and low on CPU ... but that complicates the server process). Starting a separate process per client instead (as in CreateProcess() or spawn()/fork-exec()) complicates the architecture and is very expensive because all info needed for the client reply can often be housed in the original parent process and inherited by the child (e.g. locally derived/cached DNS results). fork() leads to the simplest and most efficient architecture.
Actually I think in most cases the simplest and most efficient architecture is when your server
creates a process for each specific type of thing it needs to do and then simply delegates incoming requests. http://www.okws.org/doku.php?id=okws is a good example.
Ah, but now it's a lot harder to share anything that isn't simply coming out of a shared library; pre-cached computations, any code that isn't in a shared library (like Perl or other interpreted code), any expensive computation that must be done per-process, etc. Forking off children is virtually impossible to beat on the efficiency front; people tend to grossly overestimate the expense of a "fork".
The only way to win with the approach you suggest is if you have some sort of massively complicated server that you only ever need some small part of at any given point in time, allowing you to do a lot of swapping in and out of memory. I've never seen such a beast and can't really come up with a non-contrived use case. YMMV, but it certainly isn't a common case.
(Yes, Perl isn't exactly interpreted, but from this point of view it certainly isn't a shared binary library.)
Although I believe you're wrong about the actual utility of this kind of data sharing across processes (and also making exaggerating claims about complexity), I might change my mind if you provided a specific real-world reference example.
That's because you want to do an exec, which essentially transforms a running process into another process. I think people generally overestimate the complexity of fork on the part of the kernel, it's not all that bad. Create a new process slot, copy the VM configuration, set the 'copy-on-write' bit and the 'write-protect' bit on the pages in the memory image of the parent and return (twice!).
If all you want is a subprocess to do something interesting to the data you already have then fork is ideal. This is - or maybe was - a very common use case.
If you also need exec then why not first abstract out the fork, you need that any way, and do the exec in the child. It's one of the most elegant solutions to the problem I've seen.
Otherwise you get a whole bunch of functional duplication between system calls.
Already the 'exec' zoo is a good example of the kind of functional duplication you'd get. Adding 'forking' and 'non-forking' versions would not seem to improve matters much.
