It's still hard to explain to developers why the Content Type ID's are as they are: "one-dimensional hierarchical partly-hexadecimal unique identifiers"...
The structure is documented at MSDN here: http://msdn2.microsoft.com/en-us/library/aa543822.aspx
"Content type IDs uniquely identify the content type and are designed to be recursive. The content type ID encapsulates that content type's lineage, or the line of parent content types from which the content type inherits. Each content type ID contains the ID of the parent content type, which in turn contains the ID of that content type's parent, and so on, ultimately back to and including the System content type ID. By parsing the content type ID, you can determine which content types the content type inherits, and how two content types are related.
Windows SharePoint Services uses this information to determine the relationship between content types and for push-down operations.
You can construct a valid content type ID using one of two convention:
One special case, the System content type, has the content type ID of "0x". The System content type is the sealed content type from which all other content types ultimately inherit.
For all other content types, you must use one of the previous methods to construct a valid content type ID. "
But why doesn't a content type just have a parent property with a consistent GUID (like al the other ID's)? Basically I don't know, but the article give the 'push-down operations' as a reason, but I'm not really convinced that is the only option to achieve that. Maybe it's got to do something with performance as well.. to find out the parent will require a recursive function. Anyway, it works.
Also check out Andrew May's article with more info