We have at least passed 3 years since both the CPUs and Linux kernel support executable but read-only memory and shipped distribution kernels configure executable kernel memory as read-only. We also have the same period when syscall table (and other interrupt tables) are set read-only by compilation or by kernel code itself during boot.
I assume that the write() routine of /dev/mem does not set read-only memory as writable and a fault will take place during attack described. Thus, this attack is rather impractical. To use /dev/mem or /dev/kmem, one has to find a way to change writable memory (which will be data and not executable code) in such a way that it will cause kernel to run a desirable code with predictable results. While the kernel lacks data constraints checks in most places (usually assuming that safe and verified code runs), it is not an easy task. At least not as easy as the authors make it sound.
Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable. There are even (usually un-exported but obtainable via System.map or /proc/kallsyms) kernel functions that will do it for you. Using module interface is much more practical to achieve the result described in the article. This is how "security" products that modify syscall table with their own callbacks work.