Not that I doubt you, but what about the manual is very specific to English and wouldn't work for other languages?

From a brief look, the typography section of the manual is definitely language specific. Different written languages often have a much different typographic convention; depending on the language, different countries using it may have major or minor differences in conventions. And of course, there are different interpretations of the convention; they've included by reference a specific version of the Chicago Manual of Style. For another language, you'd need to at least need a different exhaustive manual to reference, as well as changing or reviewing the specific guidelines.

That's work that really needs to be done by a fluent, literate user of that language, hopefully with background in that language's literature and experience in copyediting, and familiarity with publishing. It's not really work you can demand of someone who did a good job (I assume) of it in English; they won't do a good job of it in another language without deep experience in that language. Developing and publishing the works in the language also needs to be done by people fluent in the language.

The example of the English version can be a guide for other languages, and there's of course room for collaboration on software between languages, but asking the English language project to expand to other languages is unlikely to get good results unless the developers also are fluent in those languages.

I'm curious, why xhtml instead of LaTeX?

When we edit, we’re literally building a standard ePub3 file, which natively uses XHTML as its document representation. The pipeline then produces alternative versions of the same file. We could work in LaTeX, but it would reduce our contributor count (more people know XHTML than LaTeX) and we’d need to transform it anyway, with the potential of introducing new bugs.