Outdated comments that explain the business use case or purpose are still better than no comments. It gives you background information how the code evolved or what it was supposed to do.

It's probably because reading comments only is worse than reading code without comments, that some devs developed an aversion towards outdated comments and thus comments in general.

Comments are additional information and no source of truth, always take them as that and read code and comments.

It’s much worse in codebases that predate version control. At least a commit shows the context of why it was added.

Yeah and over the course of 2 or 3 decades of development a lot of software has moved through several different version control,ticketing systems and developers.

So you wind up with files stating an author who no longer works there with an email address that the company used 3 acquisitions ago, a ticket number you aren't even sure what system it was for but you just know it isn't being used anymore and source control history that goes back 5 years out of a total 25 years of development.

The entropy is real.

You just described LibreOffice!

I just described a lot of offices.

Agreed. Also, comments that emphasize the "why" over the "what" are not obviated by descriptive names.

I've found it very helpful to rubber duck comments to get into the right why mode. Consider how you'd explain this piece of code to a less experienced guy on the team - and write down exactly that. Why was this added? Why was the old thing in place changed, what broke and had to be changed? Why didn't you do the other obvious thing? And remember - usually you should explain something until it's clear for you, and then one more step.