I think I'm still missing something. I assume that the rub is "GL sync is implicit *until* we start using ARB_sync and persistent maps, or similarly APPLE_flush_buffer_range", but that doesn't explain the use of glFinish(), which presumably wouldn't be required in that case. [I also don't understand why a7c320d184fb specifically adds that wait to wined3d_context_gl_cleanup()? Unless it's incidental to that change.]
It's already a while ago now, but the reason a7c320d184fb9d48239caf0f5529b6992477b82b introduced those lines in wined3d_context_gl_cleanup() is probably mostly a consequence of how that series was upstreamed; these patches went through a couple of iterations, and there probably isn't anything specifically in that commit that requires this.
However, it does simplify some things. In particular, notice that in commit a7c320d184fb9d48239caf0f5529b6992477b82b wined3d_context_gl_poll_fences() is called directly from wined3d_context_gl_wait_command_fence(). (As opposed to from wined3d_context_gl_cleanup_resources(), which was introduced in commit 7c844cd3c9c465bdeaf3d98d6da5f2f5e460e650.) Further, notice that wined3d_context_gl_poll_fences() is responsible for calling wined3d_fence_destroy() on completed fences. It would have been possible to avoid waiting on those fences before cleaning them up in a7c320d184fb9d48239caf0f5529b6992477b82b, but there didn't seem to be much of a point given the direction we were going with wined3d_context_gl_cleanup_resources() and the existing design in the Vulkan backend. Thinking about it, that does probably mean we may leak some fences when taking the glFinish() path.
As for the glFinish(), as mentioned before, we could probably get rid of it. The way I approached 3cc8147594de868884d3e57babff8eef058c63a3 was to try to maintain the existing behaviour of the code as much as possible without having to acquire a new context; in retrospect, perhaps that wasn't quite the ideal approach. It does have the benefit of not having to check the code for places that may depend on the existing behaviour, of course.
Bottom line, the original idea here was to make sure nothing was in flight here, fences and allocator blocks in particular, and then clean those objects up. It may certainly be possible to relax that somewhat. The glFinish() always was a bit of an awkward fit; on the one hand it's a fair bit heavier than the fences, while on the other hand it doesn't clean everything up.