sudo (at least everywhere I've used it) - is typically used to (A) allow me to run code as root without having to type my password, and (B) give select groups of people the rights to run a few specific commands. In terms of number-of-time executed, in a recent environment that I was in, in which approximately 100 or so people had sudo rights, 90+% of the time it was to allow people in various group to run commands like "tcpdump" or "netstat", without giving them full root rights to the system.

The correct way to set up BackupPC to run full disk backups against a remote system is to create a backuppc user on that system and then add an entry to your sudoers file for the most restrictive possible backuppc command. Here's an example from one of my servers:

    backuppc ALL=(root) NOPASSWD: /usr/bin/rsync --server --sender ?*

This primarily is to help limit the amount of damage that backuppc can do if something very strange happens and it decides to try to eat the filesystem.

Yes.

One example I've used was setting up some non-technical windows users with a shortcut they could click which would:

do a key-based, passwordless ssh login to the server rotate a proxy log, specific to their test machine

The logrotate config for these logs included code to move a copy to a mapped network share.

So clicking the shortcut caused the log for their most recent bout of testing to magically appear in a folder on their desktop.

The sudoers file allowed only this command to be run by these users. They did not get shell access at any stage.