I'm not sure how I'd do acceptance/E2E testing without the magic of port 0. As long as you have a way of capturing what port it ended up using (which most languages are able to out of the box more or less), parallelizing testing workloads becomes such a breeze without having to manage ports and all that jazz, just fire everything up with N parallism and let the OS figure out what the free ports are, pass the references down and stuff just works. Thanks Linux :)
And then there is OpenSSH...
joker@joker:~$ ssh localhost -D 127.0.0.1:0
Bad dynamic forwarding specification '127.0.0.1:0'
joker@joker:~$ ssh localhost -D 127.0.0.1:9999
ssh: connect to host localhost port 22: Connection refused
joker@joker:~$ ssh localhost -L 127.0.0.1:0:localhost:8080
Bad local forwarding specification '127.0.0.1:0:localhost:8080'
joker@joker:~$ ssh localhost -L 127.0.0.1:9999:localhost:8080
ssh: connect to host localhost port 22: Connection refused
Oh well.
> I'm not sure how I'd do acceptance/E2E testing without the magic of port 0.
Same as anything else, an explicit flag to achieve the same "just give me a port" functionality as this "magic number" does without resulting in the documented unpredictable behavior around a technically legitimate port number.
As the article points out, most if not all of the services exposed on port 0 seem to be accidental and likely resulted from people assuming this magic behavior applies everywhere instead of just to one specific API.