This isn't 100% secure though - if you're a clumsy typist and some day type "sl -l" instead of "ls -l", you run the risk of running "./sl"
If you're a clumsy typist, even if you don't have '.' in your $PATH, you might still type ./sl (instead of your intended ./ls) and get the "rogue" program to run.
I've had . in my $PATH for the last couple of decades. It's fine.
The point is that you would never tpye "./ls" when you meant to type "ls".
Or at least I wouldn't. I just grepped through (several years of) my bash logs and I have never once in my life typed "./ls", accidentally or otherwise. I consider this strong evidence.
1) that's a far less likely scenario
2) you shouldn't be running programs out of publicly writeable directories on hostile multiuser systems anyway.
3) (not directly related to your post) explicitly using ./ allows for more accurate completions, almost always making up for the two extra characters typed (particularly since ./ is so easy to type with a single motion).
If you're a clumsy typist, even if you don't have '.' in your $PATH, you might still type ./sl (instead of your intended ./ls) and get the "rogue" program to run.
I've had . in my $PATH for the last couple of decades. It's fine.