Some basic level of leetcoding should be fine to verify that the candidate can at least code and is not only a bullshit artist who jumps from one position to the next, failing upwards.
I had some interviews, not at the principal level, we had a couple of candidates who were very good during the informal interviews, they could hold a conversation about technology, but they couldn’t code the simplest of problems. I know folks don’t like it, but this could happen in my humble opinion at all levels.
I don't doubt you in the least: I've also seen BS artists who got through interviews without being able to so much as write a for() loop.
But I've never seen anyone fail upwards as far as a Principal/Staff Engineer level. Last time I interviewed at that position, no one even asked anything about code. They were more concerned about my position on architectural choices, pros and cons of various approaches, knowledge of applicable standards and regulations (I'm in the medical device field), mentoring and team leadership issues and how to resolve them, etc.
Lots of reasons you can fail an interview, doesn't mean they're a bullshit artist. If we want to be intellectually honest about this process (letting a candidate prove themselves), the least we could do is offer different formats for people to pick from: leetcode live coding, take-home, pair coding, PR review, etc.
What is key is letting the candidate decide the format they're best at.
Leetcode's signal is pretty bad compared to pair coding/PR reviews IMHO. And if the job genuinely involves writing algorithms, you can put algorithms in the code and have them go over that.
Take home is probably the most vulnerable to cheating, but if you have them code review it afterwards, it's detectable fairly easily.