The reason is what developers already know: naming things is hard! (Two hard problems, etc.)
Of course, developers also know how valuable good names are, so we like to take the time to pick good names. Users would rather just skip naming altogether and refer to things by letter/number or just by clicking on them.
I think this is one of those great insightful points that's counterintuitive and yet has abundant real-world evidence we can't deny.
I'd guess that vast majority (99%) of programmers that program in languages requiring explicit variable names (Python, C, Java, Go, etc) will still use Excel without named cells nor named columns. Yes, they will label their adjacent cells with freeform text (e.g. "TOTAL PRICE:") but they won't use the Excel "named regions" feature to be referenced in formulas. How do we reconcile the inconsistent attitude we have about the benefits of names?!?
It turns out that yes, naming cells is a form of "code documentation" and helps avoid "spaghetti formulas" -- but it's also a friction. If programmers using Excel eschew cell names, it's a given regular users will too.
It also doesn't help that "names" in Excel is not a 1st class feature. It's a separate menu item and the name is a hidden "alias" for the cell.
With other products, the "name" of the cell is what you type into the box right there on the sheet. The UI for giving a cell a name is more immediate.
I use excel a lot and I found that the only convincing use case for range names is if you need to refer to ranges from VBA, then this is the only way for the code to find its way on a spreadsheet even if someone inserts some rows and columns. Otherwise range names create more problems than they solve.
This is really like copy pasting code from one namespace into other, with code in both spaces having same variable names.
You really need to think of a spreadsheet as a function. It must have single responsibility and must be called by another sheet to be used.
But if you are copying a formula that has things like variable names into a new sheet, you have to understand that pasting the formula with its variables pointing to nothing is like inducing a NullPointerException.
//B1 is renamed as first
//B2 is renamed as second
_______________
f(x)| C3 = first * second
_______________
A | B | C | D
_______________
1|___|_2_|___|__
2|___|_3_|___|__
3|___|___|___|__
4| | | |
_______________
f(x)| C3 = B1 * B2
_______________
A | B | C | D
_______________
1|___|_2_|___|__
2|___|_3_|___|__
3|___|___|___|__
4| | | |
In programming the UI to assign names is very intuitive and right there in your face. You place the name next to the thing you want to have named. Done.
At the top left corner of the sheet, just to the left of the formula bar, there is a textbox that displays the cell Number (eg. A1). Simply click on that and enter a name for that cell.
So it does come down to a UI issue after all: the right UI for getting users to name things is one they want to use for labels/headers.
Programmers are so used to having to name things that we don't see the mental overhead of using names. A named cell is conceptually a pointer -- you can change what it points to (by giving the same name to some other cell instead), and if you delete the referent, it can point to nothing. That kind of invisible indirection is not easy for non-programmers.
https://support.office.com/en-us/article/Switch-between-rela...
From that perspective it's very telling that the editor's/document's/spreadsheet's/product's name was taken from a long-time editor for the web, Coda.