Fla already explained the rough logic behind it, but I also think a big part of it is that people have a habit of approaching advice like this too dogmatically. For example, guidance that says "commenting your code is not a substitute for sensible structure and variable names", and someone may read that and go "I shouldn't use comments, got it". Certainly I have seen (and written) code that overuses comments in a manner that the average comment has pretty low information value — for me, this was because I was inexperienced at writing code other people would use, and comments were things that I felt I should do, without properly understanding how to do it. Like if there's a line that says a += b, I don't need a comment that says "# adds b to a". That misses the point of comments entirely, and would make important comments harder to see, and the code harder to understand.

Another area where I often see this overly rigid mindset is the acronym "DRY", which means "don't repeat yourself." It's a decent principle, and it's helped me to identify larger structural problems in my code before. However, some people take it to an extreme and treat it as an absolute, inviolable law, rather than a principle. In some circumstances, repeating oneself would improve the overall code.

If I had to choose between code that had sensible variables and structure, but no comments, and code that was opaque but heavily commented, I'd probably choose the former. However, in practice, it's a "why not both" situation. It's less about the comments than how well they're used, and identifying comments as a code smell may be an attempt to get people to approach code readability slightly differently and using comments more wisely.