The last-modified headers indicate that the front page and docs have not been updated since May 2018. This is not a viable platform and the analysis of Twitter's technical shortcomings is facile. The original 140 character limit, now doubled to 280 characters, was originally constrained by the SMS interface Twitter supported but ultimately imposes a preferred content style that distinguishes the microblogging experience.
The scaling problem is what AWS's James Hamilton use to call the "Hairball Problem" in which there is no single database partitioning scheme that performs well under all workloads. The Subscriptions [1] section of the documentation demonstrates this problem:
> I immediately came up with the naïve solution: keep a list of users to which users are subscribed, then when you want to get updates, iterate over the list and find the last entries for each user. And that would work, but it's kind of costly in terms of disk I/O. I have to visit each user in the list, retrieve their last few entries, and store them somewhere else to be sorted later. And worse, that computation has to be done every time a user checks their feed. As the number of users and subscriptions grows, that will become a problem.
> So instead, I thought about it the other way around. Instead of doing all the work when the request is received, Blërg tries to do as much as possible by "pushing" updates to subscribed users.
This approach works well except when some users have hundreds of thousands of followers which results in an explosion of "pushing" updates. This doesn't even take into account geography related latencies of a global user base. Furthermore, naive attempts at databases without fault tolerance assume that losing recent data is not a big deal. It isn't, the big problem is failures that corrupt data and can't be restored to a known good state.
[1] https://blerg.cc/doc/#subscriptions