Is it really THAT bad to call $sth->finish in legacy code?

As per the documentation for DBI->finish:

$rc  = $sth->finish;

Indicate that no more data will be fetched from this statement handle before it is either executed again or destroyed. You almost certainly do not need to call this method.

Adding calls to finish after loop that fetches all rows is a common mistake, don't do it, it can mask genuine problems like uncaught fetch errors.

When all the data has been fetched from a SELECT statement, the driver will automatically call finish for you. So you should not call it explicitly except when you know that you've not fetched all the data from a statement handle and the handle won't be destroyed soon.

Now, I get how it's not needed, but the warnings in this documentation appear a bit hyperbolic. Are these warnings exaggerated? Or is legacy code that still includes finish calls as an idiomatic way to communicate intent actually a “mistake” instead of merely wasted effort?

This only came up because of a comment on stackoverflow where I helped someone simplify their code by suggesting they loop instead of manually calling prepare, execute, finish for every SQL statement. I therefore researched for more info on this, but was only able to find the following resources:

• DBI, prepare_cached, finish, and forks from Feb 2006 on PM, where some of the later nodes suggest not using finish.
• You (almost certainly) do NOT need to call finish() from June 2010 on DBI mailing list, Tim Bunce (DBI author) encouraged user to "let go" of the finish habit.
• Perl DBI when to close prepared statements from March 2014 on SO, where a user needed finish because of an outdated version of DBI. Was encouraged to upgrade and drop the calls to finish

Anyway, I aim to use DBIx::Class and other constructs instead of manual calls to DBI, so this rarely comes up for me. However, I would like to understand the actual risk of needlessly calling finish, or if this is just an effort to get people to streamline their code?