Historically .pl stood for Perl Library. This was "back in the day" before modules were introduced. Nowadays you see fewer and fewer Perl Libraries in use as people migrate to proper modules. But libraries still are put to good practical use, so the .pl standard continues to exist.

.pm stands for Perl Module. This is an etched in stone convention that exists cross platform. The use statement expects that if you (for example) use Data::Dumper Perl should look for Dumper.pm in the Data directory in one of several possible places where modules typically reside.

Because some operating systems don't have an 'executable' file attribute, and don't look for shebang lines (the #!/path/to/perl line; these are always examine d for switches regardless of OS, but not necessarily for path to Perl and association) it has become somewhat of a convention to use .pl as an extension on Perl scripts that can be associated with the Perl interpreter (perl.exe, on these operating systems). For example, in the Windows registry, if one associates .pl files with perl.exe it will be possible to double-click on a .pl file and have it invoke perl.exe, much like you could click on a .doc file and have it invoke MSWord. It is an unfortunate requirement and convention, as it makes it difficult to differentiate between a Perl script and an old Perl Library.

The .cgi convention is not set in stone. It is dependant on your webserver configuration, and could be something different entirely or not even required. It's not strictly a Perl convention, as scripts written in other scripting languages could also use the .cgi extension to alert the webserver that it's a CGI script. And like I said, there are some webserver configurations where .cgi isn't even needed.

This is discussed in greater detail in the platform specific POD area of Perl's documentation and to some degree in perlrun.