The typical model for providing kernel errata (security/critical fixes) is through providing a newer version of the latest kernel in a "dot dot" release. For instance, for Oracle Linux 6 if the current latest "Red Hat Compatible kernel" is 2.6.32-431.1.2 and a security issue gets fixed, there will be a 2.6.32-431.3.1 (or so). The sysadmin then has to install the new kernel and reboot the server(s) in order to get that fix to be active. Now these "dot dot" release versions typically only contain security fixes or critical bugfixes so while a reboot is annoying and can have a significant time impact, the actual updates are very specific.
When updated versions of the OS are released (such as OL6 update 1, OL6 update 2,...) however, the change in the kernel can be more significant. For instance when you look at the lifecycle of Oracle Linux 6 with the "RHCK" versions. OL6 GA was shipping with kernel 2.6.32-71, update 1 2.6.32-131, update 2 2.6.32-220, update 3 2.6.32-279, update 4 2.6.32-358, update 5 2.6.32-431. Each of these kernels will have pretty significant changes. Aside from carrying forward the security fixes and critical bugfixes, they typically also contain new device drivers, new features backported into older kernels. In fact, if you look at the changelog of the RHCKs you will see features from kernels as current as 3.x backported into 2.6.32.
In this case, going from one version to another is a bigger deal for some customers that have a very conservative upgrade policy. However to be current with security updates one typically has to go to a newer version in order to get the errata. Security fixes are not backported to all older versions by default, while some vendors have a support option where they will support one or 2 other kernel versions, it's relatively selective.
With Ksplice however, we make the security/critical fix errata available for all the various kernels. Not just one or 2 selective versions. So you can be on any of these kernels, and without the need for a reboot, have the fixes available. That's choice and flexibility. It reduces risk of upgrading to newer kernels to get a fix, it reduces down time to zero and increases the security of your servers.
By the way, 2.6.32-71 was released 03-Jan-2011. Since then there were 45 kernels released (RHCK), with vulnerability fixes and critical fixes, so if you wanted to remain current, that would have resulted in 44 reboots for each server since 2011 (so 3.5 years). With Oracle Ksplice, you could still be running that 2.6.32-71 kernel from January 2011, without any reboot and be current with your CVEs. Imagine having 100's, if not 1000's of servers... time saved, cost saved...
To give you a concrete example, here is a list of all the different kernel versions (RHCK) for Oracle Linux 6 :
With Oracle Linux and Ksplice you could be running -any- of the above kernel versions in your production environments when a security vulnerability gets fixed, we will make a fix available for all of the above.
Here is a list of the latest Ksplice update packages for Oracle Linux 6 with RHCK, as you can see, all the kernels are there :