But the fact is, they did think a lot about using other languages on the web, and about proper ILs as well. The fact is, there has been no good way to do either, if you want a standards-based platform with multiple compatible implementations.
You can take some existing IL like Java bytecode, but (1) that stuff is patented, and (2) there is no hope of cross-vendor agreement on what that IL should be, and all of them have various issues anyhow (for example, Java and .NET bytecode were designed with static languages in mind).
JavaScript is winning simply because it's there, it works, and everybody supports it. Yes, it has frustrating limitations, but it's hard to see a practical alternative. We will simply need to overcome those limitations - and that is possible.
I'd never heard of any discussions around determining a proper IL, though; if you can, a link so relevant MLs and such would be most appreciated.
http://www.aminutewithbrendan.com/pages/20101122
and here is him talking on HN about JS vs Python, Lua etc. in browsers,
From a technical point of view, you also need to think about how scripts interact with other dynamically loaded scripts. That means standardizing on function calling convention, symbol tables, types and object representation. There's no way to solve these things with something like bytecode (which is why there were never any Java applets that load other Java applets), you need a dynamically-typed programming language. So R4RS Scheme may have been a better choice, but that's not what Netscape marketing wanted, so what.
If the W3C or the browser makers collectively had put some thought into making it possible for other languages to be linked into the client in a sane way (i.e. rather than the existing plugin regime), or defined some proper IL that app authors could compile to, Javascript wouldn't be on its way to being the compilation target for the web.