The problem with this assumption is once it is required in practice, you can't go back in time and change the past decade. This is one of those things you have to assume will be required if it's to be of any use at all.
> Why would you need git blame if you stay at a company 2 years tops?
It's not for you tracking your own code, it's for figuring out what was going on 3 developers ago (or 3 developers in the future looking at your code).
> Why would you need git blame once your feature is effectively rewritten? twice?
To know what happened that caused them to write that really weird line in the original code, how important it is, and whether those two rewrites need something like it. I'm going through this right now, rewriting some perl daemons in python because the underlying system it uses has become so unreliable and having such svn history from 10+ years ago has been a great help - even for simple things like finding that yes, the comments are wrong because they were for a version of the code before a refactor.
> Why would you need git blame if you’re just an intern and merging & picking is done by senior greybeards?
There's a good chance you're making the seniors' jobs harder by squashing it.
> Why would you need git blame if everything is perfectly explained in the ticket linked from a PR?
You're assuming the ticket still exists. We're on our 3rd system (at least), and I'm regularly in code that links pack to a ticket system that we haven't had in almost a decade.
> Why would you need git blame if the code is clear and does not require git archaeology to understand it?
What's "clear" can be really subjective. It probably was clear to the one who wrote the original version, but for any number of reasons it isn't anymore. (Idioms from one language you don't know well, quirks of the individual developer, an original clear design that slowly mutated over time and with multiple developers and is no longer clear, etc...)