Because the problem is not creating a node (menu, etc) in two languages, that's peanuts. You either add a lang to the primary key of the node or create a (nid, nid, lang) relationship table and you are basically done.
Basically. Because with more complex node types, some things are shared. Dates of events for example are the same with a different formatting. On the other hand, places are not necessarily -- even the country names can be different. So, we either extend the node API with provisions for this (shared/not shared among languages) or every single module needs to think on this. I can't say I love either.
Sharing files have already been raised by Dries.
A normal document is usually created by someone and then it's up for consumption. But a multilangual document has a much more problematic workflow: someone enters it in one language, then a translator translates it and usually an editor checks the translation. If we assume that it's a sync'd site where every document is immediately available in many languages then we are looking at complex node access control on unpublished nodes and good workflow handling.
I end this here, but I am afraid by the time the group finishes the list we have the better half of contrib enlisted as requirement or near-requirement . What gets in core? The current (nothing) is definitely not a good approach. However, we should never forget that many, many, many Drupal sites are single language and we shall not make our APIs more complex, our code more bloated just to support the very small percentage of multilanguage sites. locale is done right -- when it's switched off, it's a very small performance penalty which in Drupal 5 serves security purposes anyways so it's not wasted.