I don't get why you think taking a portion of a GPL-licensed work means that portion wouldn't itself be GPL-licensed. Of course it is, like the whole work is.
The stance of the FSF is that game assets are not software and thus having a GPLed engine bundled with non-free assets is ok. The assets and the engine doesn't form a complete work that as whole has to be GPL licensed. Going by that interpretation taking the assets from a GPL game and including them in a proprietary work would be ok, as it's just the reverse direction of what is already common practice (see Doom, Quake, Dosbox, ScummVM). The GPL would apply to the art, but not to the engine.
The license follows the graphics no matter how you get them.
That's not the issue, the graphics will obviously stay GPL, the issue is if it does force other parts of the program to fall under the GPL. In a statically linked C project the issue is clear because all the used library become part of the resulting executable. In a lot of other context the coupling between the GPL code and the proprietary code is not so tight. Using a GPLed grep in a proprietary shell script is for example considered ok, but using a GPLed grep() function loaded from a dynamic library would be considered a violation going by the common interpretation, even so it's essentially the thing. The proprietary code wouldn't need to contain any GPLed pieces, it would just call them. In the case of graphics the only thing that couples the code with the assets would be a filename.
Things get even more complicated when you are dealing indirect couplings by third parties, not by the distributor of the proprietary application. For example assume a proprietary application provides support for themes and then a user builds a theme from GPLed assets. Is that a violation or not? What about plugins or scripts?
This whole situation really isn't clear and even the official GPL FAQ is a little vague when it comes to how to deal with plugins and basically leaves the user with a "it depends".