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?
Yes, as you've discovered, avoiding namespace conflicts is crucial. Math was unfortunate because it clashed with a heavily used CPAN top level namespace. You need to choose a top level namespace for all your non-CPAN works that is unlikely to clash with a CPAN or core Perl module. I'd look for a name that is short, descriptive of your organisation, and easy to search for. "Site" is a bit too generic for me - searching CPAN for "Site" just now returned 2457 results, while "Barrabas" returned just one (an obscure module written by one Rajstennaj Barrabas :).

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.
For more detail on this amazing infrastructure and some specific tools, see Modern Perl's "CPAN Tools for Managing Distributions" sub-section.

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:

In reply to Re: Best practices for local libraries by eyepopslikeamosquito
in thread Best practices for local libraries by Barrabas

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.