My concern about this approach is that it only allows for accepting  a single incoming connection each time the port is bound.

If the shell were to provide socket()+bind() as one operation, and then accept() as another operation, that would allow for more flexibility in how scripts deal with incoming connections, including the ability to accept multiple connections - and for users who want the simplicity of taking a single incoming connection, such a command could be implemented as a function using the socket()+bind() and accept() commands.

/dev/tcp redirection is useful, but it's also a bit strange for the shell to spoof the existence of non-existent device files so it can express TCP connections through redirection. Ideally I would say the shell shouldn't do this (at least, since it already does it, it shouldn't do it more) - but on the other hand, expressing TCP connection as redirection does allow for the connection to be limited to the scope of a command or group of commands, whereas using builtins to connect would require explicitly closing the connection files when done with them.

You can, for instance:

while read word; do respond_to "${word}"; done <> /dev/tcp/whatever

As opposed to:

tcp_connect hostname:port socket_varname   # Open TCP connection, store FD number in ${socket_varname}
while read word; do respond_to "${word}"; done <>&$socket_varname
exec {socket_varname}<>&-    # Close the connection FD

So the /dev/tcp style of approach does have its benefits, but I think it may be worth considering whether it really should be expanded.