I found this paragraph really hard to grep given how vague it is, but I'm assuming that he's euphemistically saying that his team/company was either not interested or not able to learn the language/framework. That would have been a more interesting article to me if he'd expanded on that.
If the team isn't interested in using some tech, then that's a sufficient reason itself to not use it. If they don't want to learn any language beyond what they're comfortable with, I'd be pretty concerned about that kind of culture, because it'll hurt them in the long-run.
If the issue is actually that they can't deliver rails projects to clients because corporate people can't write ruby, then that's more important than any other reason given in the article.
I didn't conduct a thorough analysis on the reasons why I've seen big corps rejecting Rails, so what I'm about to say is based on the the experience of being through all these projects.
But most Rails projects are connected to the innovation departments and once they passed through the PoC stage, their IT departments asked for a re-write on a tech already in their ecosystem. Supporting additional techs raises complexity and forces them to support another stack.
We were indeed able to push some Rails apps to production on enterprises, but these were usually apps that performed a specific goal for one of the departments, and once we went for the big projects within their core, tech stack was always an issue.