The front end is just a bunch of calls to services and HTML rendering from templates. It really has nothing to do with real time communication.

Except that little thing that shows you new tweets immediately...

That "little thing" which maintains and generates the timeline should be IO bound whether it's written in C or Ruby unless it's written by someone who does not understand the problem space, and ought to be a separate service. We can agree Rails doesn't make much sense for it, but frankly, language does not matter. Understanding how to minimise context switches for a network service and how handle fan-out does. It's not a hard problem - it's been solved dozens of times over by people writing queueing message servers, NNTP servers and SMTP servers, amongst others.

I don't disagree with any of your points. I just disagree with the assumption that twitter frontend is something static with no time-related components.

The frontend should be. It is folly to handle things like the timeline update there, where it is time sensitive, rather than as a backend process that is not - nobody will notice if their timeline is a few seconds out of date. They will notice if it takes more time for the pageload to complete.

That is just polling essentially the same endpoint that renders the page.