i assume you're compiling all your code with -O0 then lest you fall victim of the infamous NULL check elimination as the kernel itself did not long ago, not to mention SSP that must be your enemy #1 then ;). more seriously, and assuming you're talking about the constification plugin, the truth is that the patch route was tried before and it just doesn't scale at both the producer (patch writer) and the consumer (lkml/kernel devs) side.
to give you some numbers, an allmodconfig 2.6.39 i386 kernel loses over 7000 static (i.e., not runtime allocated) writable function pointers (a reduction of about 16%). creating an equivalent source patch would be thousands of lines of code and have virtually no chance to be accepted in any reasonable amount of time (not to mention the maintenance effort of being out-of-tree during the process; i've carried a small fraction of such a patch in PaX for years and it was a PITA even if the patch itself was 'only' 800k).
also by virtue of enforcing const on these types one will quickly find out all the places where variables of a given type are modified (sometimes in direct contradiction to kernel policy) and one will be forced to document it in the code (for each such exception there's a writable type to be used, based on the no_const attribute introduced by the plugin). the patch for this is about 100k, but it also includes changes that actually eliminate the need to modify a given variable (vs. just changing its type to be writable).
all in all, the cost/benefit ratio of the plugin approach is excellent and there's a lot more in the pipeline ;).