If I recall the warning in Window's is potential unintended consequences, including security issues, when another program can SO_REUSEADDR on a port that you are still currently using.
As far as I know on Windows for normal sockets, they get cleaned up, including listen sockets, along with the process. So if you close the process then restart it, you shouldn't need SO_REUSEADDR.
Windows also has a SO_EXCLUSIVEADDRUSE and my understanding is that new software should use that for security reasons.
https://docs.microsoft.com/en-us/windows/desktop/winsock/using-so-reuseaddr-and-so-exclusiveaddruse
Quote
Once the second socket has successfully bound, the behavior for all sockets bound to that port is indeterminate.
...
Before the SO_EXCLUSIVEADDRUSE socket option was introduced, there was very little a network application developer could do to prevent a malicious program from binding to the port on which the network application had its own sockets bound.
...
The SO_REUSEADDR option has very few uses in normal applications aside from multicast sockets where data is delivered to all of the sockets bound on the same port. Otherwise, any application that sets this socket option should be redesigned to remove the dependency since it is eminently vulnerable to "socket hijacking". As long as SO_REUSEADDR socket option can be used to potentially hijack a port in a server application, the application must be considered to be not secure.
All server applications must set SO_EXCLUSIVEADDRUSE for a strong level of socket security. Not only does it prevent malicious software from hijacking the port, but it also indicates whether or not another application is bound to the requested port. For example, a call to bind on the wildcard address by a process with the SO_EXCLUSIVEADDRUSE socket option set will fail if another process is currently bound to the same port on a specific interface.
Lastly, even though socket security has been improved in Windows Server 2003, an application should always set the SO_EXCLUSIVEADDRUSE socket option to ensure that it binds to all the specific interfaces the process has requested. The socket security in Windows Server 2003 adds an increased level of security for legacy applications, but application developers must still design their products with all aspects of security in mind.
Although worrying about that sort of denial of service is probably not an issue for games, and seems to assume there is already malicious software on the system. I believe it also refers to hijacking existing UDP "connections", not just a TCP listen socket, but I never really investigated this.
