That's not what I said. I said that comments can often (but not always) be replaced with good and explicit names.

This can be pushed to some extreme by making functions that only get called at a single place in the code, just for the sake of being able to give a name to the code that's inside (instead of inlining it and adding a comment that conveys the same informations as the function's signature)

It's definetly not for everyone, but for beginners/juniors it gives something objective they can aim for when trying to build good coding habits

Indeed, so now it is a code smell.

Fair enough, code from a different era smells different

They aren't saying never have complex boolean expressions...

That's not what I'm saying either. But I think this is to be judged on a case by case basis. And it can depend on your understanding of the context. I think there's simply too much nuance here to just say "this smells"

Not sure what your point is here. Of course inconsistent naming is a code smell. Do you want inconsistent names?

Of course not. But in some (uncommon in my experience) cases method names can be unclear or just plain impractically long. In such cases, I would rather see an exception to the rule than having to rely on a comment to explain the name choice.

I had a great example a couple months back, but I can't remember it right now. But here's a (bad) example of such a situation.

An example of this could be a button that triggers a click. You might call it BtnClick. Then the click event for it could be BtnClickClick. In this case, I'd rather see BtnClick_click. Ugly? Yes. Bad example? yes. But the idea is that it's more clear that the _Click action is seperate from the name.

There are arguments to be made either way, but normally you’d scope your variables in a way that the ones specific to a particular bit of code are not accessible from elsewhere.

They're arguing to do this:

int field = 1;
void may() {
   do(field);
}

int field = 3;
void you() {
   do(field);
}

int field = 3;
void be() {
   do(field);
}

int field = 7;
void happy() {
   do(field);
}

rather than

int field = 1;
int field = 3;
int field = 3;
int field = 7;

void may() {
   do(field);
}
void you() {
   do(field);
}
void be() {
   do(field);
}
void happy() {
   do(field);
}

A bad example of encapsulation would be:

class AClass {
    private class HelloThere {
         int a = 1;
         int b = 3;
         int c = 3;
         int d = 7;
         void DoStuff(AClass self) {
              Do(a, b);
         }
    }
    private HelloThere field = new();
    void World() {
        field.DoStuff(this);
    }
}

Of course, there is nuance here. Is this class encapsulating enough that it's got a right to exist? That'll depend on the situation.

Also, c has local static variables. Depending on your use case, it might just be easier in c than in C# and similar.

// a method with a state, horrid in some contexts, great in others
void PrintCounter() {
    static int count = 0;
    Print(count);
    count += 1;
}

And just in case you're still reading and curious:

#region PingPong
    // hi! I am in a region, collapse me using your ide!
#endregion

You gotta know how to use it properly