Any automated code analysis will fail for lots of edge cases, sometimes in really amusing ways and other times in just plain dumb ways. Experience and context is almost always the key to figuring out if the analysis is telling you something important or not. The key phrase from your introduction is "which has detected a couple of issues" so that's a win.

For the rest, if it doesn't make sense to you you can most likely safely ignore it: you have the experience and know the context. For the unpacking @_ "issue", I'd write it as:

# Create Embedding object
sub new {
    my ($class, %attr)  = @_;
[download]

But that's how I'd have written it in the first instance and maybe that makes your eyes bleed, so what do I know? Either version works in terms of clarity in my view. I guess what the rule is really trying to clean up is progressive unpacking of the argument list through the function making the expected function signature hard to determine. That isn't an issue with your version so I'd say no problem exists.