I recently read Shrikant Sharat Kandula's Shell Script Best Practices (via). One of the suggested best practices is:

3. Use the .sh (or .bash) extension for your file. It may be fancy to not have an extension for your script, but unless your case explicitly depends on it, you’re probably just trying to do clever stuff. Clever stuff are hard to understand.

I have the opposite view. Unless you have a strong reason, you should avoid putting an extension like .sh, .bash, or .pl on your scripts and programs. The reason to avoid it is a variant of not making product names visible in messages. Some day you may want to change that shell script into a Perl script, or a Ruby script, or a compiled program (perhaps you get an urge to use Rust). At that point, either you have to find every use of the script elsewhere in your system and change them all, or you have a '.sh' program that's actually written in Perl.

(Python is the one sad exception to this, because as far as I know having an importable thing requires your file to end in '.py', unless you want to rename your program while testing it (or use a symlink).)

I think this advice is especially dangerous for shell scripts if you use '.sh' and '.bash' to differentiate between scripts that are portable Bourne shell and scripts that are Bash specific. It's not unreasonable to move a script back and forth between those two sides depending on the circumstances and then needs (a simple script might evolve so that it now can really use Bash specific things, for example). But with script extensions, you've added a point of friction to doing that. It's not enough to change the script and rename it, now you have to also fix any uses of the script. How many developers will persuade themselves that they don't really need to use that useful Bash-ism after all? Probably not zero.

If you only write personal scripts and programs and never invoke them automatically in any way (from each other, from cron, from Makefiles or other build instructions, etc), then having file extensions is probably harmless and may help you keep track of what is what. Otherwise, please have a strong reason that you need it.

PS: One reason to do this is illustrated by the process of building Go from source, which has you run either './all.bash' on a Unix system or 'all.bat' on a Windows system (there's also an 'all.rc' for Plan 9). Here Go wants to call its build, test, and so on build commands by standard names ('make', 'all', and some others), but Go needs different scripts on different systems, so it uses the file extension to denote the implementation language and implicitly the OS type it's for.