If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem.

setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd

Could even run it as a daemon unprivileged from a home directory with "systemd --user"

That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.

For that you really only need CAP_NET_BIND_SERVICE.

The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.

For most things, you can do with capabilities

Issue is that it increases friction and you need sudo anyways to set the capabilities.

Most web servers would happy to run unprivileged with only CAP_NET_BIND_SERVICE

bin passwords I will always remember: At the University of Maryland CS department systems the bin password was "fuck,you", and there was a devout Christian student on staff who had a problem with that, so we had to change it (to something harder to remember, I just can't recall).