There's this seminal paper by Peter Naur called "Programming as Theory Building" that arrived at the exact same conclusion when it comes to programming:
What strikes me, is that everything you listed is under the "Lindy Effect", if it has been around for 30 years, you can expect to be around for the next 30 years.
Among those, I can also recommend:
Relational Databases.
Unix tools for text manipulation, like awk, grep, and sed.
Make.
Architecture patterns.
OP here, much of this paper resonates around the knowledge we need to build a system, lot of this is like the understanding of business rules, is the context we need to build a working software in the first place.
The problem is that knowledge is mostly "tacit", and tends to grow as the software evolves. For example, several development tasks are normally completed not only based on the documented user stories, but they also carry the context from meetings or discussions that aren't documented.
When you lose the original authors of the program, it becomes very difficult to rebuild the necessary context to understand how the system works - tasks like adding new features or modifying existing behavior becomes very hard. Also in the "The Metaphor as a Theory" part, much of the work is a shared knowledge between the developers, when you have several programmers working in parallel as fast as they can, the design of the program can become highly incoherent.
Nowdays we have practices like testing which could be a really helpful companion when it comes to understanding how the system works and the expected behavior of it's parts, which can be treated as a documentation, also we have code reviews that can guarantee that any addition to the system is consistent according to the system's design if is done right.
But still, this dependency of the context it's a very hard problem to resolve.
https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f...