You seem pretty vehemently opposed to all of this, so I don't think there's much/any point trying to convince you, but for the record ...
1) Static Makefiles don't support feature detection and configuration in the same way autotools do. Obviously they're not perfect, but they're a damn sight better than just writing plain static Makefiles. Converting the build system of every single project we've been working with is obviously a non-starter for any viable project.
2) This is completely possible with PulseAudio, and many vendors who've deployed it have written their own custom plugins to process streams, some extremely complex, and all without any need for custom knowledge on behalf of the applications. It also provides a number of very real benefits such as drastically reduced latency from source to hardware, and strong power savings. You can read more about this here: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinge...
3) StageFright has a number of issues, and is not particularly well-suited to more than just basic media playback (and even then ...). GStreamer, on the other hand, has been deployed in all major distributions for years, as well as part of uncountable devices (both consumer/gadget and enterprise), some of which have some hugely taxing requirements. I'm sorry to hear that it anecdotally doesn't work for you on OS X, but it certainly seems to work very well for tens of millions of people. In our Android port, it can indeed be used as part of the base system, because we're developing a branch of AOSP to use as a base for integration, rather than something you can just install from the Google Play store.
4) Wayland isn't, as you note, 1.0 yet (although it is 0.95, with a frozen core protocol), but it's something we're very interested in, as you can see from its commit stats. We think it has a lot to offer in terms of fluid and beautiful UIs which people particularly want in the mobile space, as well as media presentation. We're getting a lot of interest from both hardware vendors and their customers, so a port definitely seemed prudent.
These are all proven, solid technologies (with the exception of Wayland, which is obviously still maturing), which people have deployed and want to continue deploying on a wide range of hardware. Hardware vendors are now turning their attention to Android and only doing base enablement for the Android stack, and the number of hardware vendors who actually care about getting a proper Linux stack up on their hardware is small and diminishing every day. We don't want Android to become a completely separate silo to generic Linux, so we're trying both to offer people with Android-only hardware a much better stack, and also to use the interest from Android deployments to keep that stack more relevant so it can continue to grow and improve for everyone.
It would be nice if that weren't the reality, but what can you do?
Most of these technologies will never become mainstream Android, partially because of licensing concerns, but also partially because the Android development model is based around being almost entirely in-house within Google, rather than the traditional inclusive open source model.
Anyway, as you say, none of this will affect you in any way, so no need to be worried about it. :)
(Obviously I'm speaking for myself and not necessarily for Collabora here. One disclaimer from my brief presentation that Jake left out of the article was that I wasn't actually working on the Wayland port: it was all done by Pekka 'pq' Paalanen, but unfortunately he couldn't make it to GUADEC, so I spoke on his behalf.)