I'd just like to point out the vast vast difference between "can" and "should"...

As has been said, it is very easy to change your $PATH so that the current dir is included in your PATH. It is not a good idea because of the security issue you said you understand. If you understand the reasoning and the security issue, and you understand that the default ./ can be changed so that it is not needed, there you have it. All the flexibility possible. Have it your way, so to speak.

Well spoken...
You CAN set up a Linux system to be incomprehensible to anyone but you.
If you do this, you SHOULD not expect mere mortals to help you

Here is an example of why it can be a bad idea to have ./ in your implicit path, especially if you are running as root.

Say someone creates a script that does a "rm -r /" command, and they name the script "ls". As root you navigate to their home directory, or wherever this command is, and you type "ls" to see what is in the directory. You will get their script instead of the real ls, and will wipe out your computer.

There are usually very good reasons we do things the way we do in Linux, even through they may not be apparent to someone coming from Windows.

PS. The above scenario is another reason you should not run as root unless you need to and know exactly what you are trying to do.

If you install a program into a non-standard directory, you can always create a symlink to the executable, and put the link in a directory that is already in your PATH, someplace like /usr/bin maybe.

Why consider adding all sorts of strange directories to your path when a simple link to the executable placed in the right location can resolve the issue ?

Outside of that ./ is a small penalty to pay for a one off execution of a program. 2 measly keystrokes..

You don't have to use ./. Just add it to your PATH variable. Probably won't be too risky for the unprivileged user, just wouldn't recommend adding ./ to the privileged user's PATH. It's really not much different than DOS/Windows? There's a %PATH% variable in the Microsoft world as well it just includes ./ (if you will) by default.

It's a convention that has been used for 30 odd years for security reasons. Make sure you understand the potential consequences before you add it. That's the thing about security...it's a pain in the a** and if it works you'll never even know it. If you choose not to use it, it'll be too late before you know it. Keep in mind that spyware, adware, malware, and virii don't ask permission before infecting a Windows machine precisely because MS users generally choose not to use security.

Finally, just because you are 'in' a directory doesn't mean you want to execute a file in that directory. Maybe you navigated to that directory to execute system commands on files in that directory otherwise you would need to pass the full path to the command.

This is somewhat off-topic, but the ./ syntax is not limited to addressing files in your current directory. For example, I keep my shell scripts in a sub-directory of ~/ called (unimaginatively) Scripts. So, for example, to run my script that mounts the Logical Volumes on my USB drive, I need to run the MountUsb script, and a ./Scripts/MountUsb does the trick.

Note that the actual characters I need to type are ./Sc<tab>M<tab>U<tab>, so it goes fairly fast.

I think this is the primary issue behind the OP. The confusion is around the fact that most directories contain data files, not programs. There are just a few directories intended to store programs, and those directories should be in the PATH, making it unnecessary to think about those directories at all.

In that case, Scripts/MountUsb would suffice - the './' is unnecessary. And, as I said, I put my personal bin directory on my path so that MountUsb would suffice. But any way just as long as the bleeping thing executes, eh?

Yes, but tab compleation for commands only works for things in $PATH, so the reduced keystroke version only works with the ./ prefix.

Ah, true.