I want to open a discussion that needs a deep reflexion because the answer can "hurt" us as (mainly) 2D game programmers...
First of all, I need to give some historical background, to give a context to my question (you can skip it, but it will help to understand my personal reasons to resist to "the change")...
I've programmed a good number of 2D apps, demos, intros, map/sprite editors, game-tools and games in my life (most of them lost in time or in now faulty-optical-media backups). After some Z80 Assembler programming in the Sinclair ZX Spectrum, I switched in 199x to PC/MSDOS writing small 2D games and sprite editors directly in mode 13h (320x200), and it was really fun, sharing them via modem in "Europa III BBS". All this programming was done in either directly ASM or C+ASM. Then I switched to Slackware Linux 96 and programmed a Sinclair ZX Spectrum emulator and some games and sprite editors in C+Allegro.
Although Allegro was a nice library, I found (in year 200x) SDL to be more suitable to my needs, and was already ported to lots of platforms. It made me remember the old nice msdos' mode 13h days, working directly with surfaces (A000h memory address then) and having fast 2d-sprite-blitting routines.
A few years ago I discovered python, which is the language that I prefer currently for almost any development I do in a personal environment and pygame, and really like it a lot.
So, sumarizing, I'm a 2D-boy. I've written code in ASM, C, C++ and python since 198x always using CPU power to blit sprites on apply effects to objects or screen. I'm used to write from scratch lots of functions (rotations, transforms, scaling, etc) instead of using libraries to do it (until I found SDL/pygame). I don't like very much 3D game programming and 90% of my top games in history are 2D (Lemmings, Super Mario 3/World, Street Fighter 2, Zelda, Prince of Persia and almost any NES/SNES/PC-VGA game).
And now, the question/problem/reflexion...
Pygame performance (and SDL, and almost any 2D-programming technology before it) it's a bit about CPU power. Ok, GPU cards help blitting, but notice that almost all SDL/pygame games are medium resolution (640x480, 800x600), usually fullscreen, and maybe higher resolutions for more static/non scrolling games.
3D games work nicely with either FullHD/HDready resolutions and you can select easily the playing resolution and everything scales nicely. Also, 3D games benefit a lot from GPUs acceleration and you can run them at high resolutions at 60 fps and the GPU makes a lot of the job.
2D games are a "pain in the ass" to make them multiresolution and scale very bad to high resolutions (in terms of speed).
I'm starting to wonder how many time can I continue writing 2D programs with the classical 2D approach. I'm wondering if maybe I have to write 2D games by using 3D technology (opengl) to render sprites as faces in cubes with a background-cube and a camera pointing in a "2d view". Some libraries, like pyglet / cocos2d use this approach.
My problem is that I like and prefer the "romantic-classic" pure 2d approach. The pyglet/cocos idea of actors, scenes and 2d-3d modelling is not as nice for me than the classic "oldstyle" approach... but that 3d approach really works and their 3D-2D games work in high resolutions at full speed and in pygame you can suffer creating a hires multilayer scrolling game at 60 fps...
Check as an example the Raspberry Pi (http://www.raspberrypi.org). A 25US$ Linux computer with ARM@700Mhz with OpenGL GPU that will run a fullhd pyglet game at fullspeed (thanks to its very powerful GPU) but won't run a pygame hires game because of lack of cpu power... The same happens in other devices like tablets and mobile phones with android.
So, please, let's discuss about it: success cases, ideas, and opinions in both ways: nowadays, 640x480 / 800x600 is "low res" and games must be able to run at higher resolutions (even in HDMI output at FullHD) and in low-cpu-but-good-gpu systems like tablets, but that implies using OpenGL and abandoning the classic-oldstyle libraries like pygame :-(.