You're talking about scaling down. A lot of things already do this (e.g. my STPPC2x runs at least one of its games, maze3d, at 640x480 and just lets SDL resize it to 320x240 for the GP2X screen). This is short, simple, obvious to anyone who programs and the Pandora SDL libraries will probably have it "built-in" like the GP2X's libraries do. It's also incredibly ugly and nowhere near the best way to do things.
The problem is more pragmatic - a "doubling" of resolution is a "quadrupling" of needed CPU time, memory, etc. To show 640x480 takes four times as much data, processing, memory etc. to do than 320x240, no matter how you do it (there are certain tricks, e.g. if you are ray-casting/tracing but they can only be used in a handful of circumstances). On top of that, if you are "pretending" to be 640x480 and then showing on a 320x240, the actual resize can take significant CPU time too, even though all you're doing in the simplest case is missing every other pixel it has to be "copied" to video RAM as a properly sized bitmap.
Anything that renders at too high a res will vastly increase the requirements (literally to the point where they will kill slow hardware) and will look really ugly unless you do a lot more processing to compensate. Run MAME to see this - load up a high res game and force it to show in low res on a slow machine. Even with the best optimisation in the world, you can kill a sub 1GHz processor easily with the right games (Championship Sprint comes to mind because my 600MHz laptop can't run it in a playable manner because of it's high res, despite being able to run similar-era games very easily).
Basically, if something's designed to run a certain resolution, it's for a reason (the detail is required, it's a standard screen size for hardware capable of running the game etc.). Especially where emulators are concerned, rendering at the "natural" screen size is obvious - manufacturers of arcade equipment etc. wouldn't specify a more-expensive high resolution monitor "just because" - they are doing it because the game requires it or the machine is more than capable of brute-forcing its way through the data. That means that emulators of that system won't save anything by rendering at lower resolution.
There are a few exceptions (e.g., the programmer hard-coded 1024x768 because he felt like it) but that's about the gist of it.
Having said that, I'm looking at allowing larger "resolutions" and allowing pan/scan/zoom in a future version of STPPC2x, but mainly because you are limited in the size of puzzle you want to do on a small screen and display performance is a very minimal element of that particular set of games.
