The primary "technical" reason is that the web platform is in a transitional phase as far as foundational technologies required for cross language support are concerned.
NPAPI (plagued by security issues) is well on its way towards deprecation, and WebAssembly is still in its infancy.
Once WebAssembly matures and is more widely supported it is inevitable that ecosystems will evolve around frameworks and libraries targeting the web in various languages. In fact, rust community is actively working on preliminary support for WebAssembly.
Alternative route is to compile languages to javascript target. There are of course lot of languages that do this today, eg. there is Bridge.NET for C#, JSweet and GWT for Java, Opal for ruby, Transcrypt for python etc. However, the primary issue is that none of these languages were originally intended to be compiled to javascript and hence when they are ported to javascript the implementations end up being subtly different from the original implementations and/or the runtime characteristics end up being quite different from the original language. And porting the libraries in the ecosystem is almost always a very cumbersome endeavour.
The major problematic aspect, that is always present when you write interop layers to target javascript libraries, is that you invariably introduce a second layer of abstraction that beginners have to struggle with.
Sure you can use React with Opal and the integration layer works really well (I have used it myself) but if a beginner is trying to learn react through opal it is almost double the effort because he/she will first have to understand the original react concepts (which are explained through javascript API references) and then would have to learn how to apply these concepts through the Opal interface, which has a lost of subtly different characteristics (underscored names, different way to associate event handlers, block oriented DSL rather than JSX etc.).
To be fair, none of these subtleties are bad per se, because without them the usage will not be idiomatic ruby, but it is undeniable that they add a cost to learning curve.
The above is explicitly not a criticism towards immense work that has gone into libraries like hyperloop. To their credit, getting started with hyperloop requires adding just a few dependencies to a Gemfile and your asset processing pipeline is up and running in seconds. When I first tried it I was amazed as to how frictionless the initial experience was compared to things like webpack.
But having said that, the ground reality is that unless there is a strong commercial incentive, no one puts in the effort to maintain exhaustive parallel documentations for interop layers that mirror each release of wrapped libraries.
This is precisely the reason why it is extremely unlikely that these ecosystems will ever catch on with the popularity and momentum that javascript ecosystem has.