Querying each URL would be impractical to do on the Twitter client side, especially on a mobile device, even simply from the latency before you can render perspective. You could render the tweets with the shortened links and then reflow the text if/when each HEAD request returns, but that would probably result in a crummy, slow experience for the reader as they scroll through tweets.
Twitter could indeed have done it on their side, but just doing it themselves is more efficient for them and provides a bit of extra user benefit - the fact it's automatic so you get more room for text in your tweets, their malicious link protection, and reliability if you assume Twitter is more reliable than J Random URL Shortener.
I've updated my post to be clear that I meant more efficient for Twitter, not the end user in that case. Also, my assumption is that people use this instead of normal URL shorteners in most cases.
Regardless, URL shorteners cannot be described as beneficial for users (except those who want to track clicks on their links). They make it take longer to get to the page. They are an extra point of failure. They are bad for users. That doesn't mean it shouldn't be done, but it isn't altruistic by any measure.
Twitter could indeed have done it on their side, but just doing it themselves is more efficient for them and provides a bit of extra user benefit - the fact it's automatic so you get more room for text in your tweets, their malicious link protection, and reliability if you assume Twitter is more reliable than J Random URL Shortener.