This is indeed unfortunate behavior of perlio.c and PerlIO, if not a bug - but also a questionable expectation.

It is not necessarily the case that reading from a tainted path causes an Insecure dependency. You can do that quite fine. Taint checking only kicks in if you want to use the tainted data you get from the file in a certain fashion, which the code doesn't. So I would expect that it just works even in taint mode.

A bit of digging reveals: Using Test::More makes a difference because Test::More loads PerlIO, but not PerlIO::encoding.

• Your argument list to open is tainted, but I have no idea how the tainted $whereami affects the string '<:encoding(UTF-8)'.
• PerlIO extracts the module to load (here: PerlIO::encoding) from your open parameter. Loading a tainted module name is fatal under -T, because unlike reading, it executes code. But it loads with eval, so that fatal error is caught, and converted it to a mere warning. I have not figured out where and how this warning is caught and converted to that strange message Unknown PerlIO layer "encoding".
• This does not happen, of course, if you have loaded PerlIO::encoding in advance!

If neither PerlIO nor PerlIO::encoding are loaded, then something in perlio.c seems to try to load PerlIO::encoding without the safeguard of an eval - and throws the Insecure dependency is thrown in your face.

I would expect that open in its three-argument-form would be able to treat encoding as not tainted even if the path is tainted, and hence consider this a bug.