So, without a canvas2d renderer, the earliest we can support is IE11. If someone eventually makes a Canvas2D renderer, then we can support down to IE9 for rendering 3D things in canvas2d (but not DOM, and no WebGL). To get a feel for how slow canvas2d would be, try looking at some of the canvas2d demos for Three.js. Here's one in WebGL, and here's the same one in Canvas2D. Mrdoob put a ton of effort to get that running in Canvas2d, and the quality is horrible compared to WebGL.
As soon as we have our prototypes working, and have merged into a single project, we're likely to continue working on features for the latest browsers that have full support of the 3D APIs, and improving the performance in that area. There's lots of work to do there.
A good question to ask ourselves: "What do I want to make, and which platforms will let me do it?" Then, choose your platform and frameworks for that platform.
One of our goals is Mixed Mode mixing WebGL with DOM. It would be a lot of added overhead to make sure that an implementation of that plays well with code that is meant to support IE 9 and 10. Introducing backwards-compatible code to support incapable browsers would be a high potential for bugs and a high cost of maintenance. It just doesn't seem like an efficient idea for the goals that we have with the library (and the awesome things we want to make with it).
TLDR: someone in the community who wants support for older browsers would have to step in and take on the challenge of the canvas2d renderer (and/or a transform2d fallback renderer that works seamlessly with the 3D APIs that we're making).