They way I see this is thinking about vocabulary and language.

We can describe the world only within the limits of our vocabulary. Basically we want to describe thinking about new things with existing words.

In case of programming we are building new concepts and it might be the case when there is no word to properly describe that concept. So we try to find the best approximation. This task alone is very hard, specifically because there are two layers of modeling: first we model the domain into abstract programming concepts then we need to create a model (approximation) of these concepts that we now want to code to be able to find a word for them.

We can see it simply with a variable: we can use common names for variables which have a clear, easy to see around us purpose: counting => count/counter, indexing => index, ordering => order ... but when we have a variable that should retain an intermediate abstract value to be used futher then this concept cannot be found so easy.

Let's say we need to save the name of a class - generated on the spot - to be used further in the code.

What is the name for this variable?

- "class" - seems the first one, but in most languages this is a restricted word

- "klass" - here we are already creating a new word

- "bucket" - this is more easy to find around us as "a place to put things in", but it does not fit maybe the current code as it is a too large concept

- "intermediate_class_name" - now again this is inventing new words by glueing them together. Might work, might not work depending on coding guidelines and other restrictions

I think it goes deeper than that. We often are trying to figure out what the code is supposed to do, trying to crystalize our half-baked understanding into something solid enough to code. While in that state, it's very hard to name things, not just because names are hard (though they can be), but even more because our understanding is fuzzy. We don't really have a solid understanding of what the thing is, and our fumbling attempts at giving it a name are part of the process of trying to figure out what it is.

To echo your main idea:

We can describe the world only within the limits of our vocabulary.

Or another way to put it, you can manage scope with your toolkit of words. In a way, if I say the word ‘theft’ doesn’t exist, you are going to have a hard time expressing theft. I just defined constraints with a simple omission.

What is a thing but a name? To really name something you have to know what it is, and that is harder than you think.

The other points have their merit, but this one is the most prevalent one. Things are hard to name because they're made and used without knowing exactly the one thing they're meant to be doing. Often times there's no meaningful motivation such as 'so I can deduplicate this piece of code' which looks the same, but be in different contexts and in future be changed for different reasons.

Well, like other designed artifacts, a name should satisfy several criteria well. It shouldn't be too long to be usable, or too short to be readable. It should be pronounceable. It should capture its object's purpose fully and at an appropriate level of abstraction. It has to differentiate itself well from other names. Often a whole naming scheme must be worked out, depending on the nature and relationship of the precise things to be named. Changing any one name can create a need for many other names to also be changed, or for the named things to be rearranged or redesigned.

It is harder to express meaning accurately and concisely than ordinary expression. Sometimes you need to give different names to similar functions, which is even more difficult.

Even answering the question, "why does this thing exist"? is often only answered in terms of its mechanism as it relates to previous choices. To be able to answer it fully, you'd have to be aware of the ad-hoc architecture that is being made-up as you go.

If you're able to envision the main decomposition and flow of the program before building (or rebuilding) it, you'll be much better off. Also be mindful of invariants or points in the process where certain constraints are met. The stuff between these points are to get you from here to there.

Programming is very symbolic whereas natural language is more phonetical, so using one in terms of the other will always be awkward. I feel the best strategy is just to let variable names, for example, be pithy or terse and just use comments to compensate; this is because I’ve found comments are still necessary even with long semantic variable names.

It forces you to understand what you are doing!

It forces you to organize your thoughts. It's possible to code without really thinking, and naming things in that state of mind is difficult.

Because we write code primarily to communicate and the words we use to name things has a high impact on that communication.

Because there are so many things to name.

If there were only 20-ish, using “foo”, “bar”, etc, or “red”, “yellow, etc, or even “x1”, “x2”, etc. would be good enough (not perfect, but people could easily get used to it, just as they get used to the (mostly) arbitrary name tags we put on people in our social circles)

On top of what others have said, when programming we also deal a lot with changing requirements. Code that used to do one thing, now needs to do something slightly different. Keeping track of everything and making sure that names remain accurate takes a lot of time and effort.

Sometimes you're trying to model the real world, sometimes you're trying to represent abstract concepts, sometimes you think you know what you're trying to name but you don't ...

I think it was harder before industrial IDEs