You don't see this with curl/wget because they use user agent sniffing. If they don't think you're a browser they _will_ give you a Location header. To see it, capture a request in Firefox developer tools, right click on the request, copy as CURL. (May need to remove the Accept-Encoding tag and add -i to see the headers).
If the redirects were server side (setting the Location header), a blank referrer remains blank. Client side redirects will set the referral value.
From Twitter’s POV, there’s value in more fully conveying how much traffic they send to sites, even if it minorly inconveniences users.
% curl -vgsSw'< HTTP/size %{size_download}\n' https://t.co/DzIiCFp7Ti 2>&1 | grep '^< \(HTTP/\)\|\(location: \)'
< HTTP/2 301
< location: https://www.threads.net/@chaco_mmm_room
< HTTP/size 0 <head><noscript><META http-equiv="refresh" content="0;URL=https://www.threads.net/@chaco_mmm_room"></noscript><title>https://www.threads.net/@chaco_mmm_room</title></head><script>window.opener = null; location.replace("https:\/\/www.threads.net\/@chaco_mmm_room")</script>> You don't see this with curl/wget because they use user agent sniffing. If they don't think you're a browser they _will_ give you a Location header. To see it, capture a request in Firefox developer tools, right click on the request, copy as CURL.
A location header is nearly unnoticeable, a meta refresh page gives you a flash of a blank interstitial screen.
(Not that I had the same annoyance, just explaining the difference to the end user of the two approaches)
If the whole purpose of it is to have browsers send a Referer header, I don't think it's that bad. Even from a privacy perspective, you can configure browsers to not send that header anyway.