That does make it easier to resize a window from the bottom left corner, which is indeed where you want to resize the window from in the majority of cases.
However, if you want to resize the window from the top or from the left, that does not help you much.
While this is true, it also turns a task that takes only one action (resize the window up or to the left from an edge or corner) into one that requires three or four (move window, resize window from bottom right corner, readjust window position).
I guess, it's a question of perspective. For me, maybe due to habit, these are two distinct actions: moving the origin and resizing the viewport. And I'm actually not comfortable with having to combine them in a single interaction. More often, I do not want to combine both, especially on a larger screen. Moving the viewport or its origin is a matter of the desktop metaphor, as well as altering stacking in the Z-order. Resizing it is on an entirely different level and relates to another kind of mental model or mapping, relating to aspect ratio and field of view, which, if changed, requires a remapping of the situational awareness regarding everything that makes the desktop metaphor. (BTW, I also hate snapping windows.)
Personally, I think, it's this kind of constant overloading, which makes modern interfaces harder to use, or at least, causing them to put more strain on the user. (I guess, as interaction is becoming more and more the message and thus the media, like in constantly pulling the content area for more to load or swiping one thing away to see another thing, this is probably just as it ought to be. But this is essentially slot machine territory and not a working environment.)
Possible meant: "Window's resize widget is outside the viewport, so have to first move the window by dragging the titlebar until the resize widget is accessible, then resize, then drag the titlebar again to approximately restore the window position".
Still, this seems to be more logical to me than moving the window borders, since moving something in a suitable place first, in order to maybe manipulate it there, is much more like we would proceed with real-life objects.
(However, the window being rendered for an initial view in a way where not all the crucial controls are accessible is the real problem and arguable shouldn't happen at all. At this point, every action to fix this will probably be flawed. E.g., if we resize the window by dragging any of its visible borders, any action and/or cancel buttons will be still tied to the bottom part of the window, which is still off-screen, meaning, we're still stuck. On the other hand, dragging the window by its title bar, while maybe a more promising approach, may be impossible, as there is probably not sufficient screen estate left for this, to begin with.)
> That does make it easier to resize a window from the bottom left corner, which is indeed where you want to resize the window from in the majority of cases.
However, if you want to resize the window from the top or from the left, that does not help you much.