Mostly. The initial target is C++ and similar languages, and it will not have DOM access, but using suitable libraries (libc, SDL, etc., for example emscripten's) you can write a normal C++ program and have it run in the browser.
You can also run Ruby and Python in the browser by just compiling their C or C++ VMs. But that won't still work "like JavaScript" - their objects won't be native VM objects in the browser, it won't use the browser's GC, they won't be observable in the browser's debugger, etc.
So far all of that was already possible, and done, with asm.js.
In the future, it is a goal to work to do GC object integration, so that something like Ruby or Python could actually compile down to something with native VM objects, and that would also allow calling DOM APIs directly. (This will likely still require a compiled VM, though.)
Its worth pointing out that it would hardly be practical to expect users to download the code for the entire Ruby VM (and libraries) when they visit your web page.
If you're using a web page that is mostly just a CRUD app, sure, no-one will wait around for that, but if you're shipping a version of IPython that can run in the browser, I think people would be pretty happy about it as long as the blob can be cached and hopefully shared between sites since it's on a shared CDN.
I think you're right. While downloading a VM doesn't make sense for a small site, for many cases it could. There are also fairly compact VMs for some languages. And WebAssembly will make the VM download substantially smaller.
Caching is hard because we serve the same code from so many different servers. IPFS fixes that by referring to files by a hash of their content. Commonly used binaries will be cached on your browser, and every app will refer to them the same way.
