It's a pretty big garden [Java, .NET, Python, ruby, etc.], It's more like the wide open space where most of the world actually is, and the walls seem to be around the rest of the [non managed runtime] world these days. Most enterprise scale apps written in the last several years run on managed runtimes. Most modern frameworks and reusable code bases target them, the vast majority of the world's programmers build software for them. Furthermore, apps running on managed runtimes tend to handle stuff with scales and complexities that nothing else tries to. Why? We don't really know. It's just reality.
It does have some pesky issues. Like GC, but those can actually be solved. We've shown that. It's just that [at least the one way we know of for] solving them does require fundamental changes to things like kernel memory management. Some of the core operations we are advocating for make an actual 1,000,000x difference to how critical phases of GC behave, thereby making the difference between a practical, no-more-puases GC world, and the current one. [For some operation metrics numbers, see http://www.managedruntime.org/files/downloads/AzulVmemMet... ]
Does that make such fundamental changes worthwhile? We think so. Some may not.