Perhaps services could have different priorities, and if the wonderful systemd starts a rando user service before the system service, the system service starts anyway and the existing user service gets booted off the port.
1) You find a way to crash sshd. This might be easier than it seems. Maybe you can fill up a disk partition and cause a fatal logging error, or drive the machine so low on memory that it is killed. If sshd seems too farfetched, pretend you're compromising a less robust system service like the printing subsystem.
2) Try to start your own listener before sshd can be restarted. It's a race, and with enough tries you will eventually win
3) If you're really diabolical, you might notice that there are certain cronjobs or management systems like puppet, chef, ansible, etc that restart system services at known times or after known events (after updating a config file). You write a script to watch for these events (use inotify to event on file updates), and race it to the finish line.
There really isn't a good mechanism from userspace for systemd to police ports without race conditions. Privileged ports is a fairly reasonable way to do it.
Another attack scenario applies if the shared server hosts a web server:
If you have a shell and can bind a port, listening for HTTP requests. Example: nc -vvl 8080
Trick a victim into visiting your malicious port: http://example.com:8080/
The attacker gets the victim's cookies for http://example.com:80/ (and https://example.com:443/, if the "secure" flag is not set). And all other ports.
This attack succeeds because "Cookies do not provide isolation by port" (RFC6265 Section 8.5).
What is the fix? If only the cookie spec allowed binding to specific ports...
But an alternate fix could be requiring web browsers to only connect to privileged ports. 80 and 443, or any port <1024, thwarting the unprivileged user from exfiltrating cookies.
Unfortunately this ship has sailed and web browsers now have to support unprivileged ports forever. A more practical defense, in practice, is to consider this scenario out of scope, and/or implement application-level authentication. I am with you, and would have advocated privileged ports to defend against these attacks (with http and ssh and other services), but am not optimistic it will gain any traction. The world has moved on, and even multi-user shell servers are becoming increasingly rare (as much as I use them - still a proud Super Dimension Fortress member)
This bug is unrelated to port privileges
Privileged ports are a permission applied to bind() to a sockaddr of type AF_INET.
Privileges are also checked when bind()ing to type AF_UNIX -- aka a unix domain socket -- aka a path to a file in your filesystem.
Privileges are also checked when open()ing a local file.
It is entirely reasonable to rely on filesystem privileges to control access to regular files like /etc/shadow, or /etc/ssh/ssh_host_ed25519_key.
It is entirely reasonable to rely on filesystem privileges to control access to unix domain sockets.
It is entirely reasonable to rely on interface privileges to control access to inet sockets.
The commonality in all of the above scenarios is that it is reasonable to trust the local system regarding its own access controls. There is no such practical concept as a MiTM between a process and open() to a local file, nor is there such thing as MiTM between a process and a bind() to a local resource.
In fact, this local trust is a required component to implement a key based system (note: the need of sshd to trust file permissions to store a host key)
Clients should be configured correctly to never ask. But many won't be and that's out of your control.
So rather than binding to a port, you ask your webserver library to listen for requests on the extra file handle. De facto, this means the application author needs cooperation from their webserver library - it needs to have been written so that it has the option to listen from an open file handle rather than binding to a port and listening to the file handle it gets as a result of that bind. But since this is a reasonably common usecase, and basically just half of the normal process, you might discover that the library you're already using has support for it.
On the other hand, AFAIK docker doesn't support socket activation, so if you use docker to provide your runtime it's game over.
Other forms of activation... idk maybe the same essence. files and dirs and processes are all owned by someone.
I don't claim to have thought all angles out, and don't even claim it's a good idea, just a response to a specific point about first-come-first-serve.