For instance, try running "systemctl stop sshd" as a non-root admin user. You will be prompted for a password, and ultimately able to do it; but no setuid binary is involved.
Instead, your command is sent to an already running daemon, which performs its own policy checks to see if you are allowed to proceed, before executing the action on your behalf.
At a glance, this sounds a lot like how setuid binaries work. The main difference is that setuid processes inherit a lot of state from the calling process. As a result, there have been a lot of attacks based on setting up the environment before calling a setuid program. The message passing approach removes that entire class of attacks.
In the case of a sudo replacement, you often want that state to pass through. However, a message passing sudo can still pass the state, and have the daemon set it when spawning the requested command. Since you can pass file descriptors between processes, you don't even need to take a performance hit (other than possibly increase overhead in the time before execution starts)