Probably its main advantage is that it makes switching between Perl installations easy

That can also be easily accommodated with shell or batch scripts. (I guess that's just a homespun, poor person's Perlbrew ;-)
In any case, I don't find it a great hassle to run export PATH=~/blead-5.31.7/bin:$PATH

There are, however, traps for the unwary in simply pre-pending another perl to the path.
For example, what happens when you then run cpan -i Some::Module and the first perl in the path doesn't have a 'cpan' utility (because it's named 'cpan5.31.7') but the next perl in the path does have a utility named 'cpan' ?

IIRC, I eventually learned that I should always build blead with '-Uversiononly'. That way, the cpan utility will be named 'cpan'.
(The same issue also existed wrt other utilities if '-Uversiononly' was omitted.)

On Windows, when I switch to a different version of perl, I generally need to switch to a different version of gcc (also handled by the same batch script).
This is because, on Windows (for me, at least), each build of perl has a runtime dependency upon the gcc installation that built it.
Perl versions 5.8.8 through to 5.18.0 were built with gcc-4.7.0, followed by others built using gcc-4.8.2, gcc-5.3.0, gcc-6.3.0 or gcc-8.1.0.
Therefore, switching to another version of perl can often necessitate switching to another version of gcc.
I'm not sure that, even if Perlbrew had built these perls, it could handle the required switching of compilers ??
Come to think about it, I don't actually know if Perlbrew can be used to build perl on Windows at all. (I suspect not.)

Cheers,
Rob