Hi Chris,

Of course, we'd all try to patch the kernel, and it's unfortunate that person didn't give any reason why. I wrote the below as to possible ideas why someone might have written that cryptic note you mention.

Your hypothesis seems possibly reasonable (as to why that person wrote that), I've seen that scenario in some cases where a vendor states going to some kernel will break support with them. Here are some initial thoughts, below: (and you might know of some or all of these).

1) A unique kernel driver that will not be accommodated in the next kernel you wish to install, and if you install it, some kernel driver would not be available. I've seen (some) cases where the kernel driver can be installed in some cases through work-arounds, and at that point, support from that vendor may not be available. But if support with that vendor has expired, then that could be a moot point, perhaps.
2) There are some third-party software packages who will not support specific kernels, and if you go past a specific kernel, your support with that vendor ceases.
3) This one can be mitigated if it is the case, (most admins who deal with Oracle are aware of this) Oracle uses something called "ASMLib", and without the ASMLib updates, (especially with RHEL 5, RHEL6 is easier to deal with, with ASMLib,
4) Regardless, of course have a look at the size of the /boot partition. While this bit is rare, I've seen it happen - I had someone call me for assistance for when they attempted to do a kernel patch on a system, and it failed, because the /boot/ partition filled up while writing the new kernel, and it was a bit of a pain to fix that incident.
5) If the admin in question was doing this on a virtual server, and they did not know they had to also apply vmware tools to a kernel patch, this could be an issue. We have to update vmware tools on occasion with our patches, and certain drivers fail without an upgraded vmware tools. If for some unique reason you happen to still have a rhel 4 system, and must do a vmware tools udpate - use the manual method because the initramrd image that is attempted to be created could fail mind-way through the process, and if you do not use the manual method, it will fail silently, and your system will never boot until you go through a special process that's documented at VMware's website.

If it is a VMware system keep a snapshot of the system if possible, prior to the upgrade. If all you are doing is a kernel upgrade and you want to test it, you could install the kernel (do --not-- use rpm -Uvh to do a kernel upgrade, that will erase the previous kernel, use yum), and if it misbehaves, go to the grub instance and change it so it boots to the previous kernel.

Those are some initial thoughts, and that list is certainly not comprehensive, and I suspect some others will likely add additional possibilities, and even add needed comments to what I wrote above. Hope this helps.

added: but I would do my best to upgrade the kernel and attempt to mitigate the issue or concern involved.