This actually makes zero sense if you think about it. If the client is receiving messages via SMS, then strip the HTML. If it's a browser or API client, show a richer version.
No reason the lowest common denominator must dominate.
In most messages, the links are as important as the message itself. If you're going to selectively remove links based on how the client sees the message, then you're essentially changing the message itself based on how the client receives it. Which is wrong.
I guess what joshu was trying to say, is if you're receiving SMS, then a url with that is useless. You can't look it up on your phone, and if you can, then use twitter on your web browser instead of SMS. Even including the URL would mean you'll have to wait til you get a computer, at which point you could just visit twitter anyway.
They really feel at home within this constraint. It's very important to them that it be compatible with the 160-char SMS limit because they feel Twitter is at its heart an SMS publishing system that has grown to have other uses.
They may feel that, but they never really got that right in the first place. Twitter has a 140 character limit. SMS has a 140 byte limit. There's a 7-bit GSM character encoding which gives you the 160 characters, but that only covers basic English, select bits of other Western European langauges, and some currency symbols. So beyond those characters, you have to go down to 140 characters, and if you're in non-Latin land (like Chinese or Arabic), you have to use UCS-2, which only gives you 70 characters.
The simple Twitter 140 limit doesn't map to that at all, and coupled with the fact that Twitter SMS is disabled in a good chunk of countries, it seems silly to think of it as an SMS publishing system.
But things have been like this since ages in the software industry : think to the CON device under windows or termios under unix, to use examples that appeared recently on hn.
