I’ve always felt this argument works best in small, stable codebases with low team churn. Self-documenting code is a great goal, but in real systems the why often matters more than the what, and that context rarely survives in variable names alone. In my experience, comments age badly when they restate code, but they age quite well when they capture constraints, trade-offs, or historical decisions. The real smell isn’t comments, it’s comments compensating for unclear design.