Once, a really long time ago - at least according to the Judaeo-Christian tradition - Adam was charged with naming things. Let's pretend he didn't and the family is talking around the campfire.
The father, talking to his son, says, "I am going to snarf an elephant for blurb. Do you want to greep a mouse for me?"
"What is a greep?"
"Greep? I said get me a prud. How else can I capture a cat?"
"Is this a prud?" the son asked, holding up a club.
"No! I want that," he said pointing to a vine.
"Oh, you mean rall a foop! How can you snarf a cat with that?"
"Why would I want to snarf anything? My truff is drouu," the father said pointing to his stomach as a rumbling sound ensues.
This conversation would most likely descend rapidly into physical violence. Not only are they not using the same words for the same things, they change the words for the same thing seemingly at random. That is why the "first man" was charged with naming everything. Without that consistency, there could be no language beyond pointing. And thus was born the first standard.
This also means that the first standard was a naming standard. While I have never seen an industry-wide naming standard, there are references in most development standards from IEEE, ISO, EIA, etc. that require projects to have a naming standard that covers at a minimum:
- program names
- directory names
- function/routine/class names
- variable names
- release names (at least the numbering part)
So, the first reason we have standards is to foster communications. A derivative reason is so that we can find things. If you know that "fwd" is an acceptable abbreviation for "forward," then looking for something called "forward look-up" could reasonably be found under "ftwlookup." This is also part of a naming standard. It presents one with a list of acceptable alternatives, as well as when and where they may be used. A second derivative reason is to allow lessons that have been learned to be codified and passed on to future generations so they do not have to be constantly rediscovered.
Once we get into development, there are coding standards that detail how code should be constructed, the style the code should appear in, when code should be decomposed, modularized and/or refactored, where code should appear in directory hierarchies, etc. There are similar standards describing how requirements are to be documented, designs are to be constructed and test artifacts are to be created/organized.