On render speed, if you're trying to serialize json 1 million times a second, the benchmark you linked might have some relevance, if not, then you're being misled by looking at benchmarks like that, which measure an app doing not very much millions of times a second, so basically they're stressing the routing path and the json serialisation speed. This is unlikely to be a problem you ever encounter and if you did you'd just rip out the bits you don't need for that path - use static routing, cache json etc, and your speed would be massively improved.
Speed is not the only concern, or even the biggest concern, for most web apps, the constraints nowadays are typically in something like this order:
Clearly that doesn't hold true for all sites, but for most the order is something like that because with caching you can obviate any render speed concerns very easily. On memory and CPU usage, golang completely trounces a solution like Rails (I say this having built similar sites in both) - it's better by a factor of 10, which means you can run a pretty big site with very spartan resources.
The largest obstacles to go replacing languages like ruby as a tool for web apps is more that the libraries at present are not available for everything you might want to do (user auth, sophisticated templating, csrf, fragment caching, form helpers, orms and query builders etc), but that situation is steadily improving, and the standard library is pretty excellent as far as it goes.
But in actual world, people will be attracted by post like "Iron.io Blog: How We Went from 30 Servers to 2: Go". And like to think so we can use it do faster and easier !
Also, for start-ups, It's important to choose a language that has a certain level of performance rather than rewrite all codes later.
Something can be open-source and paid for. It is uncommon, because people can build it on their own, but Sublime Text is an obvious counter-argument: people are ready to pay for development, even when they could use it without paying.