Can you help me understand how this helps with scaling? I prefer this url format myself and noticed it's used rarely by the big guys. If there's a scaling advantage it provides, however, it's not obvious to me.
DNS is much easier to scale out than HTTP. By having full FQDN for users, you have the capability to easily scale out without needing a load balancer in front of say, threewords.me.
So in your DNS zone you can tell it to route all accounts that start with the letter 'a' to server with IP 1.1.1.1, letter b to IP 2.2.2.2, etc. Server with IP 1.1.1.1 will not only run a headless web app but also route SQL queries to a db shard (all relational data for users starting with the letter a).
This level of "user" partitioning can be deeper. So it's not just the first letter of the user but two or three more letters/numbers. So joe.threewords.me would be on a different server than j4mes.threewords.me (That's j.o.threewords.me vs j.4.threewords.me).
"twitter has servers dedicated to high-volume users without having to use urls/dns like that"
That's why they need so many load balancers w/ failover:
twitter.com has address 128.242.240.148
twitter.com has address 128.242.245.212
twitter.com has address 128.121.243.228
Load balancers aren't flexible to work with especially when dealing with sessions. I imagine Twitter's front end nodes are doing nothing but routing URLs to backends, which are doing the real work. So the front end balancer takes http://www.twitter.com/unixy and routes the actual server-side request internally (where scalability is implemented).
