I'm a big believer in consistent, readable codebases. Anything that doesn't make it easier to understand and improve the code shouldn't be occupying your headspace. You should never have to answer "now why didn't that work" with "I was supposed to use with_scale instead of withScale."
There are of course languages where the ecosystem itself is inconsistent (like PHP) or there are no conventions to follow (like CSS). In those cases, use whatever's your favorite; however, if you are snake_casing JavaScript or camelCasing Python, you're doing it wrong.
If you're the only one who ever touches your projects, it doesn't matter, but for anyone who has to work with your codebase, you've created a pain-in-the-ass for no good reason.
Of the many faults a library author can make, variable declaration style is pretty low on the list of things that are truly going to affect the product of the library. I'll always sacrifice style and convention for features such as performance, ease of use, or capabilities. Things like variable naming conventions being in line with the rest of my project are on the nice-to-have list, but definitely not going to drive my decision on whether to use a library or not.
To me, it says that the author is out of touch with the community and the commonly followed standards and suggests they're breaking other conventions (that affect the product more than naming convention)
> it says that the author is out of touch with the community and the commonly followed standards
Maybe. I suspect your interpretation may be the common one (which may be reason enough to follow the convention) but it is certainly possible that the author is aware of the convention and consciously chooses to ignore it.
If other code-quality signals (does it work? does it build? is there a demo/quick-start? is it tested? documented? readable? not re-invent the wheel? follow relevant architectural and organizational idioms, etc.) are there, this seems to me to be the more likely scenario, especially given this particular convention (which is somewhat controversial).
For what it's worth, I feel I'm pretty well versed in the JavaScript community standards and conventions and yet like the author I commonly follow an underscore_based_naming_convention rather than aCamelCaseOne in JavaScript/CoffeeScript (even in open source projects). There are some studies [1] that suggest that the underscore version is more readable in general, but I've seen earlier studies that come to the opposite conclusion.
For me it comes down to personal preference -- I find underscore-based-names more readable and easier to remember (e.g. `http_client` vs `httpClient` vs `HTTPClient` etc) -- but I concede it's essentially a matter of taste.
I'm not trying to convince you that underscores are better, just that the use of underscores in JavaScript isn't as directly related to code quality as you seem to assume.
I'm just saying that after seeing the project demo or readme on github or whatever, I would use that as just one signal as to assess the quality of the project and whether I would use it or not.
Although most Python is written in snake_casing, it there's still a few big frameworks that use camelCasing and when you're using them, camelCasing is the way to go. One that comes to mind off the top of my head is Twisted/Zope.
There are of course languages where the ecosystem itself is inconsistent (like PHP) or there are no conventions to follow (like CSS). In those cases, use whatever's your favorite; however, if you are snake_casing JavaScript or camelCasing Python, you're doing it wrong.
If you're the only one who ever touches your projects, it doesn't matter, but for anyone who has to work with your codebase, you've created a pain-in-the-ass for no good reason.