Even before Draft PRs existed, I would often encourage especially junior devs to open PRs early and just include a note (in the description or the first commit) with a "Work in Progress" or "Not Ready to Merge" type comment and then either delete that (if in the description) or add a new comment with "Ready to Merge" or similar when ready.
It's great to see GitHub add this as a real tool now, but there's always been lots of good reasons to open PRs early, evolve them rapidly with discussion, and merge them only once discussion converges. It can be a useful workflow for some types of teams.
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.
It's great to see GitHub add this as a real tool now, but there's always been lots of good reasons to open PRs early, evolve them rapidly with discussion, and merge them only once discussion converges. It can be a useful workflow for some types of teams.