I've seen people who can whip up a nice solution to an interview problem but can't plan out a larger system. Or they have some cool way of solving the interview but then it turns out they want to write 100% of their code as monkey-patches. Or they write great code but cannot get along with anyone. Or they can solve the interview but don't actually have the deeper expertise that they said they did. I'd call all of those false positives from the technical interview.
I guess you could counter that you need to have a 10x longer technical interview that covers all these aspects, but a long interview process is going to filter out all the candidates who are good enough not to have to put up with one.
This is why I wish system design questions were more common. I couldn't care less if you can do a bunch of palindrome algorithm problems on a white board. I do care if you understand the scalability, maintainability, and implications of your code. And if you understand how different data structures work and are used. Most whiteboard problems fail spectacularly at this.
I agree that, in principle, system design interviews are great. The problem is that, in practice, I have seen them generate way too many false positives. This was at great companies and with people who had absolutely stunning resumes.
I guess you could counter that you need to have a 10x longer technical interview that covers all these aspects, but a long interview process is going to filter out all the candidates who are good enough not to have to put up with one.