I am going to defend the platform, while you should understand that if you absolutely need a local webserver or database to make your development go, what I have to say does not apply to you at all.
EDIT Same goes for X11. I am an E17 user, but not on Android. I don't care about X11.
There are plenty of software out there that do not depend on Apache or MySQL. Postgres too. (I tested postgres, it also does not work.) There is nothing stopping you from using a sqlite database and they are very advanced nowadays, although if your goal is to use Go (ARM port) with SQLite, you will probably find as I did that it's not tested and not working. But the system sqlite library and client in Debian/Ubuntu is not at fault. Many Android apps (android java) depend on sqlite databases and they are IMHO the new ubiquitous data store here.
You need to re-evaluate your expectations for this platform. The shell should be a means to an end. I am thinking always, do I have a way to accomplish this task that does not involve running a shell yet? The end of all development on Android should probably be an APK, with buttons and ready to take your orders by touch, no heavy requirement of memorized shell commands. The platform is not meant to run a shell, and the shell should not be a part of your end-user product. That said, nothing stopping you... Android Terminal Emulator is a quality, finished product. I use the shell every day to ssh somewhere else and access screen or tmux. After a while I find that there are not many "standard linux" processes that I want to use on Android, past the phase of testing for "does it work at all?" level of compliance.
When you think about using apache/database, think about uptime requirements for those packages. On half of the environments I tested, the system could not stay up reliably past an average of 20 process forks in the chroot. I had to kill my entire chroot and start again. You can imagine this made apt-get completely unusable. Still, try enough times, you get the software that you needed installed. These processes don't throw away their work just because they are stopped or killed. This was the problem I experienced on Galoula's installer, and it did not occur with Debian Kit or Linux Deploy. YMMV.
These (androids) are systems that are meant to be running on wireless networks, without public IPs, and powered by batteries. If your process is going to cry when your battery runs out and the socket it's listening on closes, or if a cron job fails to fire on time, it should be deployed on a real server. Take Android out of the picture. You can get a "plain linux" system by using OLiFE installer, with no Android. Now the hardware will do what you want. It's just not Android.
But if you want to preserve the Android userland experience, and just gain access to compilers, Linux Deploy or Debian Kit are perfectly suited to what you want to do. There is nothing stopping you from connecting to a MySQL server that's hosted remotely, or pushing to a git repository. You can apt-get install libmysqlclient-dev all day. All of that stuff works. SYSV IPC is responsible for a very small subset of what we Linux guys take home / really need for development.
I would recommend against AOKP on the transformer (and cyanogen, and basically everything but stock or EOS roms) because they all seem to reboot themselves for no reason with an unacceptable frequency, and they all have "the sound bug" where you may have to reboot it yourself just to get an app to play a sound after some length of uptime / some event I don't quite understand happens. EOS has been completely free of these bugs in my experience. I only reboot when I'm feeling frisky.
BUT AOKP does not have the SYSV IPC bug. So if you are just playing, and you want to have debs that require IPC, that is your platform. Still require batteries, still other criticisms apply.