Although it was disabled in Debian bash 2.04-5 on 2000-06-05, it was re-enabled in bash 4.0-5 on 2009-09-13 and is currently enabled. See https://metadata.ftp-master.debian.org/changelogs/main/b/bas...

On two different Debian 10 boxes bash seems to have it enabled:

  Terminal 1
  $ echo hi > /dev/tcp/127.0.0.1/9999

  Terminal 2
  $ nc -vvvlp 9999
  Listening on [0.0.0.0] (family 2, port 9999)
  Connection from 127.0.0.1 57540 received!
  hi
  $

For anyone wondering, it is enabled by default on Ubuntu too. I wonder what made someone think that this was a good idea?

If you follow the everything is a file philosophy it seems quite natural does it not?

Except permissions aren't granular enough / are too confusing, it's a giant footgun with the current Linux architecture, which doesn't have all the nice things Plan9 does

I didn't say that the everything is a file philosophy is necessarily correct and well implemented on Linux. Merely that if you where to continue along this direction it would seem like a logical next step. I don't think I would use this for anything but for shell scripts at best. However especially if you are a plan 9 fanatic then it would seem like quite a good idea which is what the original question was.

I mean, unless you're host is extremely locked down you'll probably also have telnet,netcat, etc installed, so no great difference.

I'm no specialist but I'm inclined to disagree, for me it's the difference between the ability to run an arbitrary binary and the ability to read/write an arbitrary filepath

They are imaginary paths in the bash executable. They aren't usable outside it. Thus the netcat analogy.

Anything you can do in telnet or netcat can also be done in python, perl, ruby. One of those is likely installed, most probably python.

And if you think about if all applications where using files for communication blocking one program from the internet would be as simple as a chmod.