In short, "it gives some signal, it's easy, it requires less infra, and it's common so people won't criticize you for it".
- It gives some signal: I can generally rule out people who are clearly unable to write basic code (loops, good variable names, not getting lost while retracing code). In my experience, this camp accounts for some 80%+ of the people coming in for interviews, even at Google.
- It's easy: the up-front costs of asking a Leetcode-type question are low. As an interviewer, I can prepare for such an interview well with 2-3 hours of question searching and an hour or so of doing the question myself. Contrast this with "closer to real" interview questions, where you may create an entire "fake project" for candidates to work in which may get leaked. It could easily take 10-20 hours to think of a "right size project" with natural extensions for candidates, which is an eternity as a hiring manager that's hiring because they're strapped for time
- It requires less infra: you don't need any sort of "shared environment to see and run code", timers to ensure that people don't spend too long on take home questions. All you need is a shared notepad or white board
- It's common so people won't criticize you for it: "Nobody ever got fired for choosing Microsoft". These types of things have a self-perpetuating nature where people cargo cult what works for large successful companies.
I don't at all endorse asking these types of interview questions and agree that there are better ones, but I do think it's important to acknowledge there are real reasons why they get asked.