that could be a potential drawback to this module when using user-supplied strings.

Technically, that's true. However ISTM that it's much the same as saying that DBI is vulnerable by design because putting user-supplied strings into a do() or prepare() call could result in SQL injection. But that's OK because nobody in their right mind would write code which passed unvalidated user-supplied data to such methods. And the same is true for Module::Load. Perhaps moreso because in the latter's case it is easily blocked by taint mode:

$ cat tm.pl
#!/usr/bin/perl -T
use strict;
use warnings;
use Module::Load;

my $garbage = shift @ARGV;
load $garbage;
print "This is fine.\n";
$ ./tm.pl foo
Insecure dependency in require while running with -T switch at /usr/sh
+are/perl5/vendor_perl/Module/Load.pm line 77.
Insecure dependency in require while running with -T switch at /usr/sh
+are/perl5/vendor_perl/Module/Load.pm line 77.
$
[download]

YMMV but I'm perfectly happy to carry on using it in a secure fashion.

it's much the same as saying that DBI is vulnerable by design because putting user-supplied strings into a do() or prepare() call could result in SQL injection

Well, yes and no: I'm saying that yes, it's a security issue like code injection, both in that it should be seriously considered and warned about, but also in that if you are aware of the issues and know what you are doing and can use it safely, then fine. But no, it's not exactly like DBI's API, because apparently Module::Load chose to overload its load function to be able to load both modules and files, which could have been designed differently to avoid this issue.

nobody in their right mind would write code which passed unvalidated user-supplied data to such methods

Well I've seen it done one too many times, and so this statement could also be read with a sarcastic meaning ;-)