The article is explicitly about object oriented code, which pretty much tells you exactly how scoping will work, and in which contexts you drop parts of a name because they're contextually obvious.
If you have 20 different functions that all internally deal with `price`, then either you're not writing OO code, or each of those functions is in its own object type, providing a clear context on what your code is talking about.
Readers of your code are not reading only a single class's code; when I hear "20 different functions that all internally deal with price" that doesn't mean the state is shared, but the linguistic context of the project is still shared. Just because in the real world we have conversations among small groups ignored people within rooms that encapsulate sound and information doesn't mean that within a large organization we don't find ourselves confused when someone says "price" without indicating what might or might not be included in that price. If you are using terminology inconsistently within the implementations of separate classes--or as the person you are responding to notes even if you aren't but the mistake is common--you could at least provide a glossary (if not use a longer name).
> The article is explicitly about object oriented code
You're wrong, it's absolutely not.
It never once mentions being about objects, and the first half of examples don't involve objects at all.
I don't know where you're getting that from.
And even if it were, it has nothing to do with my point. Different objects could use different standards for a price variable. You claim that objects would provice a "clear context", but if it's not through variable names, then how? Just through comments around the variable names?
If you have 20 different functions that all internally deal with `price`, then either you're not writing OO code, or each of those functions is in its own object type, providing a clear context on what your code is talking about.