I've always understood one of the purposes of dependent PR support to be that we can review a series of changes ahead of time. It's often the case that there is one major change at the front of the queue of changes that takes time to review, and then simpler follow-up changes behind, particularly when backporting.

A recent case is:

1. https://github.com/openjdk/jdk8u-dev/pull/218 - main change which required review due to changes in backporting
2. https://github.com/openjdk/jdk8u-dev/pull/219 - clean follow-up backport
3. https://github.com/openjdk/jdk8u-dev/pull/252 - additional issue found during review of #218 affecting other files which are not part of #218 and so covered in a separate bug and PR

#2 and #3 were reviewed prior to #1 being integrated. When #1 was integrated, the reviews of #2 and #3 were discarded, even though no changes had been made other than the bot changing the target branch.

I think this may be a side-effect of SKARA-1584, perhaps unintended. Certainly, we were able to keep reviews back when I did https://github.com/openjdk/jdk8u-dev/pull/225

Requiring re-reviews of dependent PRs essentially removes much of the usefulness of them, as the committer has to again wait on re-reviews after the integration of the dependent PR.