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.
