Setuid and setgid (and setcap where it exists) are the only ways to elevate privileges. Other than through this mechanism, a process can relinquish privileges, but never gain them. Therefore you would not be able to do anything that requires additional privileges.
For example, the programs
sudo need to be able to run commands as any user. Therefore they need to run as root, no matter which user called them.
Another example is
ping. TCP and UDP sockets are accessible to any user, because these protocols have a notion of ports, and a process can take control of a port (which is called binding it), so the kernel knows where to send the packets. ICMP has no such notion, so only programs running as root (or with the appropriate capability) are allowed to request that ICMP packets are dispatched to them. In order for any user to be able to run
ping program needs to have an additional privilege, so it's setuid root (or setcap).
For an example of group privileges, consider a game that stores local high scores in a file. Since only actual high scores achieved by users should be stored in the score file, the score file must not be writable by players. Only the game program must be allowed to write to the score file. So the game program is made setgid
games, and the score file is writable by the group
games but not by players.
There is an alternative approach to elevating permissions, which is to start programs that require additional privileges from a privileged launcher program. When a user wants to perform a task that requires additional privileges, he runs a front-end program which uses some form of inter-process communication to perform the privileged action. This works well for some use cases such as
ping program to parse options and report progress, and a
ping-backend service that sends and receives packets), but not for other use cases such as the game high score file.