We have enough trouble with user-space code generation, and with return-oriented-programming. Actual code generation at the driver level seems utterly wrong.
I'm not sure what I think about that principle, because native code generation is exotic today, but probably won't be 10 years from now.
But either way: your statement is exactly the point the post is trying to make. It's not "Linux is insecure", or "SMEP is worthless". It's "how does native code generation interact with the roadmap of security features OS developers and hardware manufacturers are planning"? Also, of course, it's "JIT spraying is cool and fun to implement, and here's a new place to try it."
"Utterly wrong" is a pretty black-and-white judgement. A JIT in the kernel has costs and benefits. You could as easily say that the ability to load modules dynamically into the kernel is "utterly wrong," since it opens up a code-injection vector that makes rootkits and other malware much easier to write. In some ways dynamically-loadable modules could be seen as even more risky than a JIT, because a JIT can only generate a subset of all possible machine code. It would be pretty hard to write a rootkit as a Berkeley Packet Filter program.
Furthermore, you don't need dynamically loadable modules in the kernel for kernel code injection, see http://www.phrack.org/issues.html?id=7&issue=58
As to your point about /dev/kmem, to me that is just another argument against the idea of banning JITs from the kernel. There are already lots of vectors for getting attack payloads into the kernel; the JIT angle only helps an attack if you somehow can make the kernel jump to a specified address but don't have root.