TCP and UDP communication doesn't just go over a network.
If you're talking to a service on the same machine, and the port number is in the privileged range, then (in theory) you have the assurance that it's a root process and that sending messages to it is as secure as passing data to the kernel.
Unix domain socket permissions are quagmire of portability, aren't they?
It adds complexity to the app if the app also does speak over the network. It's more than just changing how you create the sockets, and a few details around that.
You will find that the detailed semantics of some of the socket operations will be different here and there.
E.g. exactly how a non-blocking connect works over a AF_UNIX versus AF_INET in all the cases that may arise; things like that.
The configuration may be exposed to the user who may have to learn to specify a Unix socket for the local case or else an IP address. If there is some configuration language, it may have to be tweaked to indicate the address type. (Could be as simple as a hack somewhere that if there is a leading slash, it's AF_UNIX).
If you're talking to a service on the same machine, and the port number is in the privileged range, then (in theory) you have the assurance that it's a root process and that sending messages to it is as secure as passing data to the kernel.