This is a wonderfully lucid and subtle comment. I think any earnest programmer who wants to get better would do well to study your contributions to this thread until they are sure they understand them.

For a domain expert in their domain of expertise, [long explicit names] are overhead.

Once you pass a certain threshold of complexity and/or time-investment, a well-designed program becomes its own domain of expertise. At that point there is great leverage to be had in finding a compact notation suitable for the recurring concepts of the system. In some ways, finding such a notation is how one ensures that the system has a good design and will keep it. As you point out, it (critically) is what enables us to keep more complex things in our heads. It also becomes an intimate part of the creative process – a good notation suggests new concepts and hints at how the system should grow.

Long explicit names are exactly what you don't want when it comes to the core concepts of a well-designed system. They are useful for things that aren't familiar and so need to be spelled out. But in a well-designed system, the most important concepts are familiar and it is a poor use of our limited cognitive capacity to constantly spell them out, for much the same reason that we prefer to say "gas" instead of "liquid hydrocarbons". Since cognitive capacity is our principal bottleneck in software, this is a big deal.

Well, I put it more politely than that, but it's a longstanding nagging issue for me, so I tend to get worked up when talking about it.

I think your point is a very valid one. I guess when I try to read a paper that's "way over my head" academically, it's fair that the authors don't care about me.

But I don't think they know its tradeoff. The way I know this is by reading the majority of intro / mid level textbooks I've had to deal with as a freshman. At that point you're not nearly a domain expert, but the texts are written in the same way.