I didn't run a POD checker; however, by visual inspection, I see four instances like

C<'escape-unicode'=>1>
[download]

Given there are also four, very similar warnings, that you had difficulties identifying, I'd hazard a guess that they're the source.

I see in your post (to which I'm replying) you've changed one of those to

C<'escape-unicode'=E<gt>1>
[download]

You may find it easier, and more readable, to use

C<< 'escape-unicode'=>1 >>
[download]

That's explained in "perlpod: Formatting Codes" (you'll need to scroll down a fair way; it's past all the initial dot points in that section).

I'd also recommend you add this as you first POD command paragraph:

=encoding utf8
[download]

That will cover any Greek, or other non-ASCII, examples you may add. See "perlpod: Command Paragraph: =encoding" for details.

"... do you have an opinion about having function names with params? I don't like it when I read a manual and it mentions only sub names."

Yes, I agree that the arguments should be documented; in addition, the return value should also be described. I would typically write the example you cite something along these lines:

=head2 C<perl2yaml>

    my $yaml = perl2yaml($perlvar, $optional_paramshashref);

The C<perl2yaml> function does ...

Arguments:

=over 4

=item * C<$perlvar>

... C<$perlvar> description ...

=item * C<$optional_paramshashref>

... C<$optional_paramshashref> description ...

=back

Return value:

=over 4

=item * C<$yaml>

... C<$yaml> description ...

=back
[download]

Although that looks like a lot of typing for every function, I'd generally set up a template for all of the formatting: that only leaves specifics to be entered. And, where you have very similar documentation, a copy, paste, and substitution can do most of the work; for instance, you could make three copies of the above then s/yaml/json/g in one copy and s/yaml/dump/g in another, and most of your work is done (the three xxxx2perl functions could be handled similarly).