That, in my experience makes it harder to review the change. To me, it's easier to do something like that while pair programming. Code review should be done once a final approach has been taken and only minor changes or factors that the implementation may not have taken into account should be addressed.
Most PR systems have multiple ways to "slice" the changes coming in to specific updates and giving you "bookmarks" for what you've reviewed prior and what is new in the latest update.
Just because it may not be your preferred workflow doesn't mean it isn't a useful workflow or that the tools don't already exist to make it a manageable workflow.
My experience with Github Enterprise is that I'll make a comment and someone will commit a change, but the reference to the change is far removed from where my comment text is (especially if there are many comments made between my commit and the commit that addresses it).
And if there are many other such commits addressing different comments, it gets difficult to find the one that specifically addresses the code I commented on.
So, I essentially need to skim through the diff again to find the code that I commented on, open another tab to find my comment and uncollapse it if it's outdated according to Github, and switch back and forth between the tabs to see if my change has been addressed. If it hasn't been addressed, I need to start a new comment thread on the updated diff.
That, in my experience makes it harder to review the change. To me, it's easier to do something like that while pair programming. Code review should be done once a final approach has been taken and only minor changes or factors that the implementation may not have taken into account should be addressed.