some of my files conflicted with system ones

Of the various things you wrote, I'd identify this as a central issue. I would suggest putting all your modules in their own namespace, for example MyProject:: or MyCompany:: - see also On The Naming of Modules, in particular, if these are modules that are always going to remain local and that you're not going to put on CPAN, you might also consider Local::.

And is there a standard place (in my home directory) to put the directories containing the library files?

There's More Than One Way To Do It... since you say it's just per-user, then really any place in your $HOME works, and using PERL5LIB set up in a ~/.bashrc or ~/.profile is fine (keeping in mind that you might want to append to the environment variables it if they're already set from elsewhere).

You might have a look at local::lib, which will add ~/perl5/lib/perl5 to PERL5LIB by default. However, personally, I consider ~/perl5/lib a directory I can just clobber anytime so I can re-install everything from CPAN - so in fact, you might want to consider setting up a really basic Makefile.PL for your modules, such that you can make use of the default Perl installation mechanisms. See ExtUtils::MakeMaker - for example, consider developing your modules in some directory like say ~/dev/MyModule (which you can add to a version control system), which could have a directory layout like:

~/dev/MyModule/Makefile.PL
~/dev/MyModule/lib/Local/Math/EM.pm    # Local::Math::EM
~/dev/MyModule/lib/Local/Math/Levy.pm  # Local::Math::Levy
~/dev/MyModule/lib/Local/Math/Log2.pm  # Local::Math::Log2
~/dev/MyModule/bin/script.pl
~/dev/MyModule/t/*.t                   # (optional but recommended)
[download]

And a Makefile.PL as simple as:

use ExtUtils::MakeMaker;
WriteMakefile(
    NAME      => 'Local::Math',
    VERSION   => '0.01',
    EXE_FILES => [ 'bin/script.pl' ],
);
[download]

Then, in ~/dev/MyModule/, you can just do the usual perl Makefile.PL, make, make test, make install, and with local::lib set up properly, it'll all just work; plus it makes it easy for you to expand your "distribution" with more tests, and it'll be easier to grow into a "more proper" distribution, like declaring dependencies and adding more tests. Also distributing to other machines will be as simple as:

make distclean    # if you've previously run "perl Makefile.PL"
perl Makefile.PL
make manifest
make dist         # will create a Local-Math-0.01.tar.gz for you!
[download]

I think your idea of keeping your configuration files separately is a good one, since that's not something you'd want to keep in a "distribution" like the above. You could also have a look at the Config:: namespace on CPAN for plenty of pre-made solutions.

A related question is where to put executable perl programs that are specific to my login. Is there a "bin" directory position within my home directory that's seen as standard or typical?

~/bin is added to PATH as part of the default ~/.profile on Debian-based systems, that's usually what I use for site-local stuff (Update: I probably should have said "user-local" stuff). Or, local::lib sets up ~/perl5/bin, which with the above suggestion will also "just work".

~$ perl -e 'print map { "$_\n" } @INC' 
/usr/local/Cellar/perl/5.26.2/lib/perl5/site_perl/5.26.2/darwin-thread
+-multi-2level
/usr/local/Cellar/perl/5.26.2/lib/perl5/site_perl/5.26.2
/usr/local/Cellar/perl/5.26.2/lib/perl5/5.26.2/darwin-thread-multi-2le
+vel
/usr/local/Cellar/perl/5.26.2/lib/perl5/5.26.2
/usr/local/lib/perl5/site_perl/5.26.2
[download]

BEGIN{
        use File::Basename;
        ($name,$path,$suffix) = fileparse ($0);
        print "path: $path";
        push @INC, "$path/perl";
}
[download]

So, I might prepend a BEGIN block and push the local path to @INC. I just looked it up, here's what I did in a script some time before: ...

I'd suggest using the lib pragma (which unshifts instead of pushing) in combination with FindBin instead; $0 can in some cases be unreliable, and the code is shorter. So if there are .pm files in the same path as the script: use FindBin; use lib $FindBin::Bin;.

Finally, into some scripts I copied every module needed, also cpan modules, getting a huge single script.

See fatpack and pp, although with some modules they have issues.

Thanks a lot, that's good news.
You remember me why I married perl a long time ago ;)

I have a directory "Math" containing several files "EM.pm", "Levy.pm", "Log2.pm", and so on. Should I place my library dirs in a subdir "Site" so that I have to "use Site::SomeDir::SomeLib" for each library, to avoid namespace conflicts?

What are the best practices for storing locally generated libraries?

Perl provides a lot of flexibility, there are many good ways to do it. Some excellent free and general advice can be found at Modern Perl:

You may choose never to release any of your code as public CPAN distributions, but you can use CPAN tools and conventions to manage even private code. The Perl community has built amazing infrastructure. Take advantage of it.

It's important to distinguish between a module and a distribution - again see Modern Perl for details, especially the "Designing Distributions" sub-section. Note that a distribution contains a unique name and single version number (often taken from its primary module). Instead of lumping all your modules into a single monolithic distribution, consider breaking them into a set of (highly cohesive, loosely coupled) distributions, all under the same top level namespace. Your comprehensive set of "Math" modules, for example, looks like a natural choice for a distribution.

The most important aspect of any module is not how it implements the facilities it provides, but the way in which it provides those facilities in the first place.

-- Damian Conway in Ten Essential Development Practices

Oh, and don't forget about the importance of getting your interfaces right. A couple of related Perl Monks nodes I wrote a while ago:

• On Interfaces and APIs (discusses the dark art of Interface Design)
• Writing Solid CPAN Modules

This is the way i do/did it: ~/lib for my libs and ~/bin for my executables. /usr/local/lib and /usr/local/bin for the stuff to share with other users - sometimes. Different namespaces like Company::Project or KGB::Gorgeous. Extensive usage of perlbrew. Using a versioning system may simplify things. Regards, Karl

Echoing some other ideas here, I recommend putting all your utility code into modules in your own namespace (in a version-controlled directory) and then:

1. Quick and dirty option: add a symlink to your modules into an existing perl include path
2. More robust option: use Dist::Zilla to build actual packages of your modules, which you might even decide to publish on cpan

The first option will get you up and running the quickest, and even help transfer your modules around (along with bug fixes for your modules) from computer to computer with the help of git. You use the existing perl lib path, so no need to clutter your scripts with "use lib ..." boilerplate. If package management looses your symlink you can put it back easily. You can also add your modules to every lib path of every perl you use while only maintaining one copy.

Later, when you find time to learn Dist::Zilla and clean up your APIs, you can make them into official perl packages which you can install into system-perl or into per-user perlbrew using "cpanm MyPackage-version.tar.gz".

Quick and dirty option: add a symlink to your modules into an existing perl include path

The OP mentions using apt-get install, which strongly implies he's using a Debian or Debian-derived system. A default Debian install will have /usr/local/lib/site_perl in @INC for precisely this purpose. But this does, obviously, make any modules linked there available to all users on the machine rather than user-specific, which may or may not be acceptable to the OP.

Really, though, the only real problem I see in the OP is the bit about the user's $PERL5LIB carrying over to root when using su. My solution to that is, quite simply, to use sudo instead, as it does not carry over the original user's environment:

me@host:~$ export FOO=bar
me@host:~$ echo $FOO
bar
me@host:~$ sudo -i
[sudo] password for me: 
root@host:~# echo $FOO

root@host:~# exit
logout
me@host:~$ sudo bash
root@host:/home/me# echo $FOO

root@host:/home/me#
[download]

If you prefer su over sudo, you should be able to get the same effect by using su - or su --login to open a login shell with a fresh environment instead of preserving the previous shell's environment. From the Debian 10 version of man su:

       For backward compatibility, su defaults to not change the  current  di‐
       rectory  and to only set the environment variables HOME and SHELL (plus
       USER and LOGNAME if the target user is not root).  It is recommended to
       always use the --login option (instead of its shortcut -) to avoid side
       effects caused by mixing environments.

and, from the Debian 8/9 versions of the man page:

           Note that the default behavior for the environment is the
           following:

               The $HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS environment
               variables are reset.

               If --login is not used, the environment is copied, except for
               the variables above.

               If --login is used, the $TERM, $COLORTERM, $DISPLAY, and
               $XAUTHORITY environment variables are copied if they were set.

               Other environments might be set by PAM modules.

So just add --login to your su command and $PERL5LIB won't be carried over to your root shell.