In my opinion the reason why programming interviews are the way they are is that they are primarily testing for a kind of person rather than programming ability. They are testing for the kind of person that is willing to jump through hoops.
Mostly, I think this is just the result of companies looking to satisfy mainly three competing tasks. One, how do we assess someone can code. Two, making a standardized interviewing approach that many different people can perform. Three, doing it all in a time/resource efficient manner. Obviously code reviews satisfies the first but present very serious reproducibility and time requirement issues. I posit that programming leetcode style questions is the solution that most companies think balances the three. It feels bad as the interviewee because it is a fairly specific skill of programming that you need to practice and you cannot opt for another method to better illustrate your ability.
That's true, but it is meant as a different filter when applied to a large number of candidates.
I went through a bunch of leetcode style interviews last year with some very odd interviewers - the oddest was a Sr Principal engineer asking me to manipulate linked lists with recursion.
And the comment he made after I wrote the code was that "We don't care if you write code at work, but we want to know you like writing code enough to not see it as beneath you to do. To make sure you're not some whiteboard architect, because everyone you are supposed to lead will be writing code."
I had been looking at the interview as a sort of idiot catcher before that point, but suddenly it seemed like a good filter for respecting the effort at the lowest level of the profession.
Google invented this interview style 2 decades ago basically as an intelligence test, and it's been the status quo ever since.
That's all there is to it.