In theory yes. In practice, nobody has made this supposedely good for the hacker / engineer system. Otherwise I'd be using it. Since your post is just parrotting the usual anti-decentralized stuff with extremely strange motives, and ignoring obvious facts such as that bittorrent works perfectly even with the legal threat to using it, lets move onto a new topic: What such a system would look like.
I don't want 2FA, phone auth, certs. I want to connect to a service providing my own public key as auth and authenticating it against a known public key which is saved on my computer. I can secure my computer however I want. I also don't want to use a badly designed roundabout way to do this like X.509 with cert pinning. I can just have a <1000LOC lib written from the ground up to do all cryptographic tasks.
I don't want my software to have """human readable""" names that are stored in a centralized directory where they conflict with others with character sets (and restrictions on them) that change every month. Instead, I want content-addressable code (functions, types, etc) which I have a dedicated editor for that allows me to write code against them.
I don't want a weird character set full of unknown functionality like ASCII. I don't want to have untyped data where I or my code is forced to make insecure ad-hoc decisions on how to interpret it (is this ASCII, CP*? UTF?). I don't want a crappy ad-hoc fly by night serialization system (each with its own gimmick such as "speed", "readability") like protobuf, yaml, yet another yaml, toml, yet another toml that doesn't solve any semantic problems associated with serialization. I don't want that protobuf lib where there is no documentation on how it maps types to protobufs and in some cases it leaves pointers initialized to null and in some cases it initializes them to point to an empty struct, based on some stupid intuition I was supposed to pick up if I become a fanboy of this particular serialization lib over the 10,000 others.
Instead, I want to use the same editor mentioned before to view data, which is just data of the ONE programming language on this computer. Algebraic data types serve this purpose almost perfectly. This problem was solved in 1970. I want one serialization format which is just a set of steps on how convert data of one type to bits. Then when I receive this data, I will view it in this editor. The point being that we don't care how the data looks on wire, because it's universally decodeable with the most common tool of the OS.
I don't want multiple programming languages that are each overly designed around strawmen like "the user" and "speed" and "C-like", with tons of edge cases such that even if I learned one well enough to be able to write sound code (you can't: https://stackoverflow.com/questions/16159203/why-does-this-j...), it wouldn't matter because your program relies on components written in 15 other such languages.
I want the only language to also be at the very least, such that I can understand what it does on a syntactic level. Again, you can't:
https://stackoverflow.com/questions/8115522/a-unicode-newlin... https://stackoverflow.com/questions/17707290/set-a-variable-... https://stackoverflow.com/questions/17662815/how-does-java-d...
I don't want to have to check what ports my program uses and check if the web browser (of course, I don't want a web browser at all) on a malicious page can send a request to those ports that will be processed as some administrative function; I want things not to pointlessly listen for no reason by default in a non-composable way. Instead, I want a program to have a list of channels that only I as the computer owner can choose to link up with other programs I choose to have it communicate with (this is known as the capability security model).
I don't want to host data, I want to refer to them by links in a self organizing anonymous content addressable storage like Freenet. I want to use the same system to distribute code.
I don't want my programming console (essentially what *sh is, just an extremely poor version of it) to be implemented on top of some obsolete tech called a terminal, that you couldn't even explain to the typical software engineer 20 years ago, that goes bezerk when certain characters hit it and has ui interaction quality comparable to a 5 year old's javascript program.