I continued with my research:
I have ported the same application to starling. It is exactly the same, but with specific parts of Stage3D, as the upload of images right after loading each one. The images are the same size (1920x1080) as the displaylist/gpu app of the previous post. I have left the image decoding parameter as it was: ImageDecodingPolicy.ON_LOAD
Swiping relatively fast from one image to the next gives the impression of a worse user response compared to the gpu version. When the app ends transition to the current photo, preloads next and the user interface is completely blocked during about 500 milliseconds. This time is mostly gpu upload... There is no more overhead: just preload, decode, upload. Tried Scout, timers, all things.
Display List/GPU mode
The app is exactly the same (without gpu upload), but in this one you can swipe to the next despite being loading and decompressing the next photo without so much pause/stutter. The user response is better and the UI blocks much less time. You can continue swipping photos without waiting for the next and you can see both (current and loading one) moving at the same time without the big pauses of the Stage3D version. Buy nowhere near the experience and perfection of the ipad native app (or even the Android ones).
The "smoothness" of both apps is more or less similar when photos are already loaded (between 55-60 fps sustained "without" stutters).
In this case (relatively "big" images in stage3D apps) interestingly if I change the policy decoding image to: ImageDecodingPolicy.ON_DEMAND (the default, less desirable in principle), gives a better impression to the user. Swiping to the next image (loading one), the ui locks, but the process of uploading the image never coincides when moving or transitioning from one photo to another, so in this case more smooth feeling is obtained. In my opinion, in this case is perhaps best ON_DEMAND as image loading policy.
Another option is to develop this "photo gallery" functionality with feathers, the list component, virtual layout (just 2-3 images in memory) and "delayTextureCreation", activating it when there is scroll by the user (or transition), so that the textures remain in a "queue" until the scroll/transition ends (feathers... or develop something similar, with "texture queue", just for photo galleries). I have no idea how the ui could respond with "big" pictures because I've never tried these sizes with this framework.
All this leads me to the conclusion that "perhaps" the gpu mode might be best for most types of applications. If Adobe had followed developments in this way, it is likely that we were at a point where there would be fewer problems than when using Stage3D (more optimized gpu mode, feathers and different visual components for gpu mode, etc). All this talking about 2D because stage3D was initially for 3D, and here it must have more advantages, but in 2D there are many questions ... In fact I think if starling (stage3d) is widely used in 2D is just because there are many more "updated" things (components) for it.
I guess many of you thought and tried all these things, but I find it curious that nobody seems to give a lot of importance to the limits of working with Stage3D. Perhaps most develop games/applications in which everything is always loaded into memory (when starting a level or zone), but things are not always as "simple".
The final conclusion is that Flash / AIR is very far from native for certain types of developments. With all loaded into memory a "near" experience can be achieved, but for developments that need to load and unload "unlimited" resources (new/destroy/upload images, etc) of a certain size, the technology becomes invalid, either through gpu mode or Stage3D.
Some may have other ideas that do not have occurred to me.