exec considered harmful?

Is 'exec' an abstraction leak wrt 'client code'? When a program wants to use some other bit of code to do something, there are a number of ways it does it, including:

• open a socket and send a request/start a communication
• spawn a program to do the thing

Out of these two, the commonality is "I want to invoke someone else's code to perform a service for me". One is saying: "I want to talk to a process which is already running", the other one is "I want to make a new process".

So in order to decide which one to use, your code needs to have an understanding of what a process is, and also how the service you want relates to that concept.

This seems like an irrelevant-to-client-code implementation detail of the service being requested; why should the client know or care if a new memory space and thread must be created to best handle what it's asking for?

This degree of freedom also ends up papered over as necessary:

• A library may be used to abstract the difference, providing a function which internally communicates with a running server or spawns a new program as appropriate.
• Some programs even when exec'd, just tell a running server to start a new instance in its own process (examples: chrome, gnome-terminal)

So my thought is perhaps 'exec' really shouldn't be used by client code. Perhaps it wants to be something more akin to an administration command, like 'mount'.
Perhaps in the days of yore, to exec or not exec was a useful degree of freedom, but these days I'm not sure.

If we were going to make a brand new unix, perhaps systemd would be in charge of execing things; the OS would maintain a registry of installed services, and new programs could invoke those things in some standardized way; it'd be up to the service whether it wanted to spawn a new process, new thread or whatever, to handle a given request.