Edits to file description pages schedule recursive refreshLinks jobs unnecessarily. Right here: https://gerrit.wikimedia.org/g/mediawiki/core/+/8a3a9e2162ed771c696a4b30925e7ae50541d3c8/includes/deferred/LinksUpdate/LinksUpdate.php#317 (added in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/105830)
This is done "in case the title is or was a redirect", but the majority of edits do not change redirect targets. There is probably no other case where an edit to a file description page can affect the links tables of pages using a thumbnail of that file. It can't affect cascade protection either (since for files, it only protects the file and its description page, and doesn't cascade into transcluded pages). We should only schedule them when needed.
These jobs perform lots of unnecessary work. I've found this while investigating T343859 – many of the errors in that task on Commons can be traced to these unnecessary jobs. There are some huge, slow-to-parse pages, that include hundreds of thumbnails of actively edited files, e.g. https://commons.wikimedia.org/wiki/Commons:Quality_images_candidates (and its 30 translations), and these jobs are parsing them over and over again at all times.