To be honest, I don't know what most languages "are" with regards to the casing convention..and I've never been explicitly told what they should be either.
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.
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.
[1] http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn...
All I'm saying is that I would use that as one of many signals to judge the library and see if I'm interested/able to use it.
How does being out of touch with the community affect how good a library is?
Since then I've resolved myself to the fact that in almost all things CS, there are many different ways to get to the final answer or finished product and your way of doing it is fine if it gets the job done in a timely manner while minimizing future complications. Anyone claiming a "right way" to do something at the level of irrelevant casing either has a larger organization to worry about in terms of code readability, etc and is therefore justified if your project is meant to be shared with others OR is professing code piousness as a way to stroke their own ego.
I would actually say that coding style is a big predictor of how likely an interview candidate would turn out to be a good developer in a team. Casing isn't irrelevant at all, it's a predictor. It has nothing to do with piousness. Another indicator of bad java developers (in my experience) is those that write near 'c', lots of for(int i=0; i<.... and not using language constructs that are their to reduce bugs. Another good indicator I have found (in java) is little to no use of 'final'.
If you'd have prefaced your coding in the interview with "I'm not familiar with Java, I use X, but I'll take a stab at the problem" I'm sure the interviewer would have been less worried about your style, but if you claim to know a language, you'll know the conventions too.