It should be easy.

Agreed, and I know issues like this can be frustrating to debug, so I hope some clarification is helpful:

the @INC is correctly updated ... That fails because cpan didn't update @INC environment correctly. ... the user environment @INC is updated by cpan

Sorry, no, because it's not cpan's job to change @INC or the environment. cpan just installs modules into the directories that are available.

installing modules as root to avoid the issue for a user is also a work-around, and not a good one

Well, if you're installing modules into the system Perl, then normally only root has access to those directories.

Here's a brief and slightly simplified overview of what's going on here:

• Perl is compiled with a default set of paths of paths for @INC. For the system Perl, these are usually under /usr, and can be written to only by root. You can install modules there via the system's package manager (preferred, because otherwise there is a small but nonzero chance that a module installation can mess up the system Perl, and that's a huge pain to clean up), or with sudo cpan or a manual install performed with sudo. These modules are then available to everyone and don't require any changes to @INC because the paths are compiled into the perl binary.
• Unfortunately, Image::Grab does not seem to be available as a precompiled Debian package - if it were, it'd probably be named libimage-grab-perl. So the approach to use cpan is fine. (Side note: you might want to check out cpanm, a nice alternative.)
• What happened here is that when you run cpan as a normal user without sudo, on the first run modern versions of cpan will detect that they don't have write permissions to the system directories compiled into perl. It will then offer you some alternatives, the default being the use of local::lib.
• local::lib will set up a directory, by default ~/perl5/lib/perl5, and it will also set up environment variables, normally by appending them to .profile or .bashrc, which do two things: First, they direct Perl's module installation tools to install modules in the new location. Second, it sets the PERL5LIB environment variable to point to the new directory. PERL5LIB is the environment variable that perl looks at for additional entries for @INC. This is why, when you log into a new shell, things "just work": PERL5LIB is set up correctly because .profile and .bashrc are run at login. It also means that it only works in the login shell of that user.
• When running from cron, things are different! cron only provides a limited environment to the programs it runs. This means that PERL5LIB is not available by default there. You can see this yourself in action by running this from the shell: perl -MData::Dumper -e 'print Dumper($^X, $ENV{PERL5LIB}, \@INC)' and then putting the same thing in a crontab entry (redirect the output to a file, e.g. >/tmp/crontest, to capture the output) and comparing the outputs.

The solution is to fix the root cause.

I hope you see now that the root cause here is the environment provided by cron.

This being Perl, there are a bunch of different solutions: a bunch of different ways to set PERL5LIB so that it's available even when scripts are run by cron (one example), other ways to set up @INC so that it always includes the directory where the modules are installed, and ways of installing modules so that perl can always find them (as I've described). So many, in fact, that I don't think listing them all here will be very helpful - each has its advantages and disadvantages, also depending on things like whether you need the modules to be available to all users or even all scripts that you want to run, and so on. So I'll just make a few suggestions of solutions (not workarounds!), and if you need more information, feel free to ask and provide more details of how you want your setup to look.

• You can keep using local::lib, and as I've said before you can set up PERL5LIB in your crontab, since this really is the root cause. It's pretty simple: From your shell where things work, run echo $PERL5LIB, then take that value and stick a new line PERL5LIB=... at the top of your crontab (like PERL5LIB=/home/darren/perl5/lib/perl5).

• Using perlbrew, you can install your own version(s) of Perl into your home directory (by default under ~/perl5/perlbrew). When you install Perl into a single directory like this, the nice thing is that it does not spread its library paths (the ones compiled into the perl binary) all around the system - instead they are all contained underneath that one directory, no fiddling around with PERL5LIB or local::lib necessary!

  So for example, I just used perlbrew to install Perl v5.26.2 on one of my Raspberry Pis. I disabled the local::lib environment variables, and now can do perlbrew use perl-5.26.2, and then use cpan to install modules into that Perl normally. And, I can now run that copy of Perl from my crontab via /home/pi/perl5/perlbrew/perls/perl-5.26.2/bin/perl, with access to all the modules!

• Although as I said, installing modules into the system Perl has risks, if it's only one module and this is just a single-user system (in my experience on a Raspberry Pi one just tends to stick with the default pi user), the risk isn't too great. Since you've already got local::lib set up for the normal user, it might be easiest to not try and clean that up, and instead log in as root via sudo -i and then just run cpan from there. The advantage of this method over the above two is that the modules become available to everyone.