Linux apps generally expect a full software stack. Android's userspace is radically different (and for good reason). There's no GNU libc or GNU coreutils or GTK/Qt or X. There's a minimal libc implementation, busybox, and an Android-specific framebuffer-based GUI framework. From the source it appears that Google have tried hard to exclude GPL'd code as much as possible, too.
Getting Linux apps to (natively) run on Android isn't really affected by this news. The kernel was already as close as it needed to be. It's userspace that's the issue.
No busybox in android; that too is GPL software that Andy Rubin and the pre-Google Android people didn't want to ship. They actually hacked up a minimal "toolbox" to avoid shipping it. Sad, really.
It's just the standard fear. Shipping GPL code you didn't write means that you need to honor a license in ways you might not forsee. Some people view that as a scary risk and some don't. Rubin is firmly in the "GNU is for commies" camp. Shrug.
You can recompile most Linux apps to work on an Android phone now. Anything requiring graphics will require a complete rework, though, because Android doesn't have X.
No. All this means is that the delta will be lower, and new kernel work will be able to cross-polinate a bit more easily. Though manufacturers don't really follow the mainline's upgrade path, and it seems like they will converge on this (embedded LTSI) instead: https://lwn.net/Articles/484337/
Afaik this means the converse. This will help run Android apps on vanilla Linux systems (eg desktops). Note that kernel is only one piece of the puzzle, but with these patches porting userland should be easier.
* It is a terrible, terrible interface that doesn't belong in the kernel
* Linux supports SysV IPC because other Unices do, Binder is at least as popular
Before you pile in and declare your reasonableness by endorsing the latter position, please understand that the former is not exactly on thin ice.