I would say that’s it only become a convention recently and I still haven’t seen any good arguments as to why loosing the distinction between callable and non-callable objects would be a good thing.
Your example does indeed look bad, but also goes against the advice given in the article so I‘m not sure where you’re going with it.
As for function vs variable, we’re getting into hair splitting territory. If your variable is a function, then name it as a function; all non-anonymous functions are variables anyway, so I don’t see the need for the distinction.
For modules, my convention is generally to name them like functions and like classes if they provide factory functionality; like mentioned in the article.
In short, my recommendation was to name number, string, array and other basic object types in snake_case to easily make it obvious that they are purely data. It makes for nice quick understanding of the code.
As an example, does
object.sendAddress point to a shipping address or a function that sends an address somewhere? With camelCase, we can only rely on the foresight of the one who wrote it to have come up with a better name, but when using snake_case, it’s immediately obvious without looking it up.
In the end, it’s a personal preference, but I definitely prefer the transparency in snake_casing and in my experience, it makes things clearer for junior developers.