The debate here is whether scripts should have an extension, e.g. to have a foo.sh or foo.pl or whatever, versus a plain "foo". Some argue that an extension should not be present, as who cares what foo is written in. If your foo.pl gets rewritten in C or whatever then you either need to keep a foo.pl shim around that execs over to the new foo, or to break everything that used the "foo.pl" interface. Without the extension, this problem does not exist—replace the script foo with the binary foo, or the binary with a script, whatever, you're done. I'm very much in the "no extension for things in PATH directory" camp, so look elsewhere for reasons why one would want to keep the dot-whatevers tacked onto random things.
One compromise is to use the extension in a version control repository (where it may be handy for loading editor configuration specific to the extension), but to install an extension free whatever onto the system:
$ echo foo.*
foo.pl
$ grep foo Makefile
install -m 0555 foo.pl ${PREFIX}/bin/foo
This compromise may complicate testing, as depending on what is being tested there may or may not be an extension on the file.
Dot-scripts (or binaries) in PATH mostly look like version numbers, e.g. tclsh8.5 or tclsh8.6 and all the different autotools versions, or less common variant selectors such as fsck.{ext2,ext3,...}. Apparently Audacity needs e2fsprogs? There's also some wacky rpc.lockd, ld.ldd, and such, and not very many *.pl or *.sh, but probably too many like why does ghostscript have a lprsetup.sh?
$ findin \* | wc -l
2851
$ findin \*.\* | wc -l
66
$ findin \*.\* | fgrep .sh | wc -l
5
$ findin \*.\* | fgrep .pl | wc -l
4