Porque esa es una característica del shell (de ksh, copiado por bash), y solo del shell.
/dev/tcp/... no son archivos reales, el shell intercepta los intentos de redirigir a un /dev/tcp/... archivo y luego hace un socket(...);connect(...) (hace una conexión TCP) en lugar de un open("/dev/tcp/..."...) (abriendo ese archivo) en ese caso.
Tenga en cuenta que tiene que escribirse así. cat < /dev/./tcp/... o ///dev/tcp/... no funcionará e intentará abrir esos archivos en su lugar (que en la mayoría de los sistemas no existen y obtendrá un error).
La dirección de la redirección tampoco importa. Si usa 3< /dev/tcp/... o 3> /dev/tcp/... o 3<> /dev/tcp/... o incluso 3>> /dev/tcp/... no hará ninguna diferencia, podrá leer y escribir desde/hacia ese descriptor de archivo para recibir/enviar datos a través de ese conector TCP.
Cuando haces cat /dev/tcp/... , eso no funciona porque cat no implementa ese mismo manejo especial, hace un open("/dev/tcp/...") como para cada archivo (excepto - ), solo lo hace el shell (ksh, bash only), y solo para el destino de las redirecciones.
Ese cat - es otro ejemplo de una ruta de archivo manejada especialmente. En lugar de hacer un open("-") , se lee directamente desde el descriptor de archivo 0 (stdin). cat y muchas utilidades de texto hacen eso, el shell no lo hace por sus redirecciones. Para leer el contenido del - archivo, necesita cat ./- o cat < - (o cat - < - ). En sistemas que no tienen /dev/stdin , bash sin embargo, hará algo similar para las redirecciones desde ese archivo (virtual). GNU awk hace lo mismo para /dev/stdin , /dev/stdout , /dev/stderr incluso en sistemas que tienen tales archivos, lo que puede causar algunas sorpresas en sistemas como Linux, donde esos archivos se comportan de manera diferente.
zsh también tiene soporte de socket TCP (y flujo de dominio Unix), pero eso se hace con un ztcp (y zsocket ) incorporados, por lo que es menos limitado que el enfoque ksh/bash. En particular, también puede actuar como un servidor que ksh/bash no puede hacer. Sin embargo, sigue siendo mucho más limitado que lo que puede hacer en un lenguaje de programación real.
Parece estar confundiendo las ideas o leyendo un archivo y ejecutando un comando. La diferencia entre datos e instrucciones.
La página principal de Google no es un programa ejecutable. Y si lo fuera, no sería seguro ejecutarlo.
Los caracteres de redirección (incluyendo < y > ), se utilizan para dirigir datos a un comando.
Podríamos hacer cat < /dev/tcp/towel.blinkenlights.nl/23 Sin embargo, esto no funcionará para /dev/tcp/www.google.com/80 ya que este puerto no responderá hasta que enviemos GET / HTTP/1.0\r\n\r\n
Así que intenta
{
printf >&3 'GET / HTTP/1.0\r\n\r\n'
cat <&3
} 3<>/dev/tcp/www.google.com/80