The only thing that connects them is that RoR was trendy yesterday, and Go is trendy today.
If this is the rationale for replacement, the author will be writing plenty of "replacing" articles in the years forward.
Go is for writing small, focused, paralellizable and likely distributed services. If I wanted to crunch data, I'd try Go.
I'd expect, say, a RoR app to connect to a Go service for some of its heavier domain logic. I'd neither write a RoR-type app in Go, nor a Go-type service in RoR.
Rails works great for things like authentication, creating a nice and maintainable UI, handling billing code, sending emails, managing the database schema, and all the web related stuff.
Erlang and Go work nicely for all the "heavy work", think sending tens of million of push notifications quickly, crunching data etc.
They can communicate using a shared, Rails-maintained database, and things like Redis to trigger updates or orders.
You can even do Erlang-backend processing of Sidekiq payloads, pushed from the Rails side etc.
All in all: use each tool for its own strengths.
Nothing that Go cannot do. The only difference between Go/web and Rails is the maturity of the libraries.
Of course Go libs are way less mature for various "business tasks".
But well: do what works for you, really :-) I'm not commenting to persuade you, I'm just sharing one data point.
I've tried writing web front-ends in Go. It's a fiddly pain in the arse, and the benefits aren't really obvious. If it works for your situation then use it, but IME they're targeted at different problem domains.
I don't like frameworks like RoR or ASP.NET MVC. Too much magic. Things break in weird places. They're slow. But they give programmers some kind of safe, happy sandbox that hides the "scary" web.
It's a whole different philosophy I think. Almost every week I see a new rubyists on golang-nuts looking for the "RoR equivalent" in Go-land.