It looks like yes, from the FAQ [redhat.com]

Redhat does not want CentOS to quickly produce compatible releases, doing so would encourage people to use CentOS rather than buying Redhat.

The CentOS 6 debacle was at least partly caused by:

1) Redhat not making publicly available some information regarding rebuilding the sources.
2) CentOS being a closed development group that refuses to accept any help from outsiders. Scientific Linux is another clone of Redhat that was able release their version of Redhat 6 much faster.

RHEL 7 Beta is based off Fedora 19, with a 3.10 kernel. Usually their beta cycles run about 6 months. Oh, and they heavily backport to their stable kernel (it is "stable", not meaning crashes less, but referring too the fact that the API/ABI doesn't change when they release updates).

2.6.0 came out in 2004, 3.0 (the next after 2.0.39) in 2011. You are not being very precise saying 2.6 related to redhat kernel. But, about to your point, Redhat/centos 5.x came with kernel 2.6.18 (released in 2007, still had the same kernel version in RedHat 5.10 that came out last october), and Redhat 6.x, that came out in 2010, had kernel 2.6.32 (released in 2009). As enterprise distribution, what matters is stability, and certification for 3rd party software, not having the latest versions, all is tested with an specific kernel version, and that kernel (and in general, packages) are kept in the same version, backporting/patching fixes when necessary, and you won't have to worry about a newer version of a sofware changing a configuration file format or keywords and stopping working after updating. Anyway, you can still install extra repositories (like EPEL [fedoraproject.org]) that will give you newer versions of some packages.

If you want to use something bleeding edge, you can try Fedora, Ubuntu, or another of the desktop distributions

I have had occasion to run into a kernel bug (back when AMD64 was still a new adventure) and, due to being at a large organization that regularly paid Red Hat various sums of cash, was put in direct contact with high level support. I provided them with my analysis of what was apparently going wrong and a C program to reproduce the failure in a short time (otherwise it would only occur naturally after a system had been running jobs for several weeks to months). Within a day or two they sent back a custom patched kernel that fixed the issue, and later rolled that fix out generally in the next update release (though, admittedly, that second part took quite some time). I might be a competent programmer but diagnosing and fixing a fundamental problem in the kernel and then being on the hook if it has undesirable side-effects isn't something I'd want to do myself, nor could I expect such a rapid answer from the community for what was basically a small corner-case problem, but one that was affecting our business. Having the support is what made the difference.
Of course, for many cases, self support and community support can be good enough, but all it takes is one major issue where you can't solve the problem and you're losing revenue and reputation, and all the sudden that "expensive" support starts to look really cheap in comparison.

And I also agree, stay far far away from Oracle Linux if at all possible (heck stay away from Oracle altogether if you can, but that's frequently impractical).

Its actually about time. We old timers remember when RedHat was free and support was the money maker for RedHat. Then they split to RHEL and Fedora, that was bad and caused a lot of initial distrust of RedHat. Fortunately, RedHat didn't screw everyone and is doing largely the right thing.

The problem with the RHEL/Fedora split was it made two different strategies. If it were not for CentOS, RHEL may have lost a lot of business. Now that Oracle wants to steal RedHat business, keeping CentOS viable keeps the mind-share of people who neither need nor want support using the equivalent of RHEL while RedHat keeps its customers.

"The question is, how will RH help Centos? That isn't very clear from this announcement. "

It does mention that we (RH) have hired the core CentOS devs - that is, we're giving them a paycheck to work on CentOS full time, we're not hiring them to do other stuff instead. And it mentions that RH has offered CentOS some resources to improve their build infrastructure, though CentOS is still deciding whether to take that offer up or not.

It's very easy to do. I've done the reverse (RHEL to CentOS) on a few occasions. It is generally as simple as installing a single -release rpm.

Don't redefine words. It's a blindingly obvious abuse of the service agreement for RHEL. It's wrong. It's not stealing. Your abuse of language weakens the point you wanted to make.

RHEL is only free as long as all you want is the source. The binary costs money, even if you go with the cheaper "self support" option.