First status report on Lincity-NG:
Just optifying the Debian Squeeze packages isn't sufficient because the compiled Debian binary actually needs libxml2 functions that the Maemo version doesn't provide. I guess compiling Lincity-NG against Maemo's libxml2 would solve that.

As an alternative I installed Lincity-NG in Easy Debian where it runs fine with the following command line:(-f = fullscreen; -s = use sdl)
On my N900 (overclocked at 850MHz) the scenario "good times" (approximately 1/4 of the map covered with buildings) uses about 80MB of RAM and 60-80% of the CPU without changing anything in the scenario (building or destroying something). The game runs at normal speed and everything sems to work fine. In the menus the GUI looks a bit cramped due to the low resolution (buttons partly overlapping each other) but it's completely useable. In game the interface is fine, just like it was made for this screen.
Pulseaudio uses additional 12-25% of the CPU unless the game is started with the parameter -m (=mute). Alsa in Easy Debian is spitting loads of warnings but the sound is working fine as long as the overall CPU usage doesn't reach 100%.

A mayor problem I encountered is that after hitting the quit button in the main menu the interface just freezes and doesn't return you to the desktop. Since the interface covers the whole screen and grabs all keyboard inputs you have no chance of getting out of the game if you started it via debbie and have no ssh connectioon from another computer to the N900 to kill the lincity-ng process remotely. I even tried to get other application on top by opening the lens cover or making a call to the phone but although the other application is displayed on top lincity-ng still has the input focus. So the only chance to get out is a reboot.
If Lincity-NG was started from within the Easy Debian desktop Ctrl+Backspace works so you can kill the game from a terminal.
I don't know if this problem is exclusive to Easy Debian or if it would appear in a version running natively on Maemo too.

I had a look at the source code to figure out how much OpenGL code there is. It's all concentrated in the src/gui/PainterGL directory and it's only a hand full of files. Until today I had absolutely no knowledge about the differences between OpenGL and OpenGL-ES but as far as I understand it up to now the main differences are in the lack of the glBegin (and end) function and the missing double data type. I greped the source code for these keywords and there seem to be no double variables in the OpenGL code and only six appearances of glBegin. So I think porting the code to OpenGl-ES shouldn't be too hard for someone who's familiar with that topic (any volunteers? ). My hope would be that using OpenGL-ES instead of sdl would significantly reduce the CPU usage making it playable even on non-overclocked devices or with more complex maps. Is that realistic?

Bottom line:
If we'd be able to port the game to OpenGL-ES and can sort out the quit button issue I believe the game has great potential, playing in the same league like Boswars, Neverball or Supertux. The cramped interface is only a cosmetic problem at worst.