Back in college I was a teaching assistant for CS classes and graded a lot of what was very often very poorly written and majorly undercommented code. But I do remember once getting an incredibly unnecessary 2 page long comment for a 10 line function.

That may be the only time that thought has gone through my head.

At my first internship, the code base had basically no comments in it, but was in general very clean, very organized, and there was a ton of thought put into naming and organization for readability. It was a good exercise for me working like that because it forced me to not rely on comments to explain messy code. But I also remember having long debates about what to name a variable to make it perfectly clear to the next person reading this code what it does (and often times ending up with excessively long variable names) and thinking "wow...this is a waste of time. You could just add a 1 line comment"

Consider the standard Java cough paradigm used by multitudes of developers, and on by default in many Java IDEs:

    /* Gets the person's name
       @returns the person's name */
    public String getName() {
       return name;
    }

That is insane. The comment adds nothing to anyone's day and helps no one better understand the method than after simply reading the method signature.

It generates auto-docs, which are useful. It's just a ridiculously verbose way to do it, and it would be preferable if the documentation could be generated without the repetitive comment.

"I can't recall the last time in 15 years that I thought "this code has too many comments!""

I've thought that every time I see a source file that contains an automatically generated header built from the revision history.