I do NOT want the encrypted passphrase in cleartext within the script.
I also do NOT want to set an environment variable with env command or system() to avoid exposure in the process list.
Instead, I use BORG_PASSCOMMAND with a dotfile with specific permissions. 'export' in a shell script uses a process environment only accessible to that user.

At the moment I only use Arch and Ubuntu/Debian systems, so the package list dump only checks for these. This can be expanded as needed.
Since I don't backup the entire system, I'd rather just do a quick dump of packages and script a reinstall as needed.
This would be obsolete with Ansible (which I will ideally use later down the line).

I generally do not care to backup the entire system, and only want things in /home or configs (usually in /etc)
I use a case statement to add or remove things as needed per system. Probably not the most efficient and it's a bit ugly, but it's very clear/easy to read, debug, and modify as needed.

I'd prefer to avoid using root when possible, especially since I don't want to backup the entire system.
If I'm only copying /home and config files, I don't see a reason to use root, and would rather just use a local user.
HOWEVER, there should not be a concern with using root. The networking is done by SSH and RPC, not Borg. If there is a security concern, it would be with SSH and RPC, which is probably an acceptable risk.
Since I'm ideally only copying config files, there should not be an issue with duplicated space or long copy times from (example:) /etc to /home.
I'm also using single-user systems. If these were multi-user systems, there might be another discussion since there would need to be a "/home admin" that could access all files in /home.

Mixture of laziness and old habits. Borg has made it easier to use client/server mode without mounting drives, and I just haven't kept up with the times.
I will ideally be modifying this to use client/server mode in the future.
Nothing particularly wrong with using a mount, it's just slower since every operation has to go over the network.

If sudo is used in the backup script (like I do when stopping/starting certain services), it is recommended to put NOPASSWD for that specific command for that specific user in a /etc/sudoers.d/<appropriately_named_config_file>
Putting the permissions in the sudoers.d file is recommended for a few reasons:
1) Those config files stay on upgrades, while content added to /etc/sudoers may not
2) PAM authentication reads and respects it. If you put the same info in just the sudoers file, PAM conversations may (and likely will) still fail
It is recommended to not run the entire script as sudo, and it's also recommended to give nopasswd to only specific commands and not to all sudo prompts

Automation

Automation is done with systemd, but cron can be used if preferred.
Change the times and users for each system. If not running as root, be sure to replace systemd unit user variables with the actual user of the system.
I have no need to have the drive mounted full time (backups are on NFS mounts only used for backups), so I also have systemd mount the drive for the backup, then unmount when done. Be sure to change the drive mount as well for each system.
For the mount service, the unit name and 'Where' setting MUST match. For example, for "Where=/mnt/mountpoint/backups", the unit must be named mnt-mountpoint-backups.mount
I set specific backup times in the timer unit rather than a random time +- midnight (OnCalendar=daily with a RandomizedDelaySec) so I have predictable, known times when things may be down.
The timer and service must have the same name (except for the .service and .timer part of course).