It's weird to me how people will slate low quality code, but think it's okay (or inevitable) to let comments go out of date. If your comments aren't useful, delete them. If they are, keep them up to date. It's part of behaving responsibly towards the rest of your team just as much as writing readable code is.
Not having used Android 4? As noted in the article I installed it manually on my Xperia Arc (CyanogenMod)... I've also played with Android 4.2 quite a lot - but then again that was not the point of the article.
fucked-up Emacs config my ass. In all likelihood I've been an Emacs user much longer than you and happen to know quite a bit about what's frustrating common (and not-so-common) Emacs users. Such configs are designed to spare them the effort it took people like to me to develop them and achieve good productivity. And I don't feel that anything is lost on them - since everything is still there... Such configs are just useful starting points - they are not set in stone...
In all likelihood I've been an Emacs user much longer than you
According to your CV on Github, you're a few months older than me. I started using Emacs in 1999 on my Rev. B iMac running MkLinux. I also have code in the Emacs core, maintain cperl-mode, and wrote eproject (which seems to be pretty popular these days). I've also taught Emacs to high school students. So it is quite possible that I know what I'm talking about.
Such configs are designed to spare them the effort it took people like to me to develop them and achieve good productivity.
They may be designed to do that, but how are you sure your design works? Do you A/B test? Do you have any data?
My philosophy differs from yours. It posits that people will not learn things though being forced to do something; people will only learn if they have internal motivation and easy access to facts. The real world is not a bunch of cookie-cutter problems that can be solved by applying a set of rules. The real world is too complicated for this, and in order to be able to navigate in the real world, you have to build skill and intuition. You do this by practicing with an eye towards improvement. If you don't have intuition, you are just a wet bag of protein, fat, and water acting like a very shitty computer. And no set of configuration files is going to give someone intuition.
Let's talk about disabling the arrow keys. I get why you want to do that. The arrow keys are far from home row, and the context switch takes a long time, and that distracts you from what you really want to do: your work. If you tell someone that they might believe you, but they won't really believe you until they try both ways and decide which is better for them. It might be that the habit of pressing the arrow keys is impossible for them to break, and using the Emacs navigation keys will never work for them. By not giving them the choice, they won't ever be able to use Emacs at all, and that's worse than using it wrong until they decide they want to try to improve a bad habit.
Learning is a feedback loop, and if all you get is negative feedback, you won't learn. By starting at the "end" (your "ideal configuration"), the user misses all the learning that he would have experienced by starting from the beginning and working through until the end. He needs positive feedback to get started, and that means using the arrow keys until they actually become a bottleneck for him. In the mean time, his brain can be put to better use; learning his programming language, learning about incremental searches, learning about the kill ring. Eventually, all those things will be so second-nature (through focused practice) that he'll be looking for new ways to make himself even more productive. At that point, it becomes worthwhile to try and break the arrow keys habit. But before that point, it's not worthwhile.
With a one-size-fits-all configuration, you teach people that Emacs is brittle and that they are dumb. And that's the opposite of reality; Emacs is flexible and the user is smart!