The "local" being referenced by the documentation of cpanm is according to the package local::lib (see man local::lib). This is a distribution-neutral directory hierarchy mainly intended for use when you don't have permission to write to root-owned paths. Meanwhile, the "/usr/local/..." paths in CentOS are just paths that RedHat thought should be added in accordance with the Unix Filesystem Hierarchy. For comparison, Debian has a completely different idea of what they should be:

/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.26.1
/usr/local/share/perl/5.26.1
/usr/lib/x86_64-linux-gnu/perl5/5.26
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.26
/usr/share/perl/5.26
/usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base
[download]

When I run cpanm normally (no -l option), it installs to /usr/local/share/perl/5.26.1, so my cpanm (supplied by debian) seems to know about the debian paths and understands that it should be using the "local" and not "vendor_perl" paths.

Are you sure that your cpanm was going to do this wrong without the -l option? And was it the cpanm installed from CentOS packages? If so, maybe ask on the CentOS forums? I think your symlinks are not a bad workaround; just add one more for the x64 subdirectory and you should have a working solution.