Using a dot, as in "foo.bar", would...
* prevent us from doing something like `$(LanguageManager).on("foo.barDefined")` since jQuery will parse that as the "foo" event, belonging to "barDefined"
* prevent us from doing something like `LanguageManager.languages.foo.bar` since JavaScript interprets the dot as separating property name, requiring us to use LanguageManager.languages["foo.bar"]` instead
* prevent us from doing something like `{ defines: ["language.foo.bar"] }` when adding meta data to extensions since the dot has special meaning there, too (inspired by Kevin's proposals)
* require developers to remember to escape the dot when using regular expressions with languages

An underscore doesn't have any of these problems.

Putting restrictions on this aids in maintaining consistency. Imagine CodeMirror were stricter.
* Then ALL modes could be loaded via `require("thirdparty/CodeMirror2/mode/<name>/<name>")`. However, this doesn't work for the two rpm modes since they deviate from this convention.
* Then we could detect mime modes by checking whether they contain a slash. But we can't, because the gfm mode defines a mime mode named "gfmBase".

Sticking to very basic things can make things simpler and less error prone, and if we manage to make due without dots in variable names, we shouldn't miss them too much in language IDs, too. I just like to be conservative here, I don't think being flexible in the language ID is an awesome feature that makes this API vastly better, nicer, simpler, etc. So I don't think it hurts to be strict here. So why risk closing doors?