“Simple problems” often aren’t as “simple” as the retrospectively sound if you consider everything like stress level, mixed mindset of the interviewee (they’re not just thinking about a programming problem, they’re also thinking about social queues, mixing conversing in, peer judgement, and loads of other anxiety inducing factors), etc.
The software industry is notorious for underestimating overall complexity factors, understanding uncertainty, and time to manage them and interviews seem to be no different. So “simple” problems are often good (I agree with you) because they’re actually not so simple for most people when you factor everything in, they’re often reasonably challenging under the set of circumstances.
Meanwhile genuinely difficult problems (in any arbitrary setting and longer timelines) require a whole lot of rote training and reusing little clever idiosyncratic techniques that may or may not be generally useful, so you very often end up with a question lottery on whether you already know how to address the problem in question or not correctly vs having some problem where a reasonable solution and expectations around that can be derived in the time (and environment) it’s taking place. Lots of nonsense.