It's not a bug. In the depth and darkness of Episerver legacy, we used to call the ContentTypes PageTypes. It would be a significant breaking change for too many solutions to change this property match. 

Either way, the ContentTypeID is the current property name of the PropertyDataCollection instance in the underlying ContentData class from which the PageData object inherits, but only when using the Content model. 

Criteria searches do not use the Content model to look for data. Instead, they rely on stored procedures. This can be proven by looking into EPiServer.DataAccess.Internal where the ExecuteCriteria method runs your search (specific to PropertyDataType.PageType) using this code

case PropertyDataType.PageType:
    if (criteria.Name == "PageTypeName")
    {
        command.CommandText = "netPropertySearchString";
        this.ConfigureStringCondition(command, criteria);
        command.Parameters.Add((object) this.CreateParameter("String", DbType.String, ParameterDirection.Input, (object) this.Escape(criteria.Value)));
        break;
    }
    command.CommandText = "netPropertySearchValue";
    object obj = PropertySearchDB.StringToInt(criteria.Value);
    this.ConfigureCondition(command, criteria);
    this.AssignSearchByValue(command, "PageType", obj ?? (object) -1);
    break;

Check the netPropertySearchValue stored procedure in the database for a deeper understanding of what's happening. Looking further into this, we have to understand the MetaDataProperties of  (EPiServer.DataAbstraction.MetaDataProperties), here you will find which property names are usable when using low-level functions like criteria searches.

public const string PageTypeName = "PageTypeName";
public const string PageTypeID = "PageTypeID";
public const string PageName = "PageName";
public const string PageLink = "PageLink";
public const string PageParentLink = "PageParentLink";
public const string PagePendingPublish = "PagePendingPublish";
public const string PageWorkStatus = "PageWorkStatus";
[Obsolete("Virtual Path Providers are no longer supported, remove usage of this property type")]
public const string PageFolderID = "PageFolderID";
public const string PageContentAssetsID = "PageContentAssetsID";
public const string PageContentOwnerID = "PageContentOwnerID";
public const string PageDeleted = "PageDeleted";
public const string PageDeletedBy = "PageDeletedBy";
public const string PageDeletedDate = "PageDeletedDate";
public const string PageSaved = "PageSaved";
public const string PageChanged = "PageChanged";
public const string PageCreatedBy = "PageCreatedBy";
public const string PageChangedBy = "PageChangedBy";
public const string PageMasterLanguageBranch = "PageMasterLanguageBranch";
public const string PageLanguageBranch = "PageLanguageBranch";
public const string PageGUID = "PageGUID";
public const string PageVisibleInMenu = "PageVisibleInMenu";
public const string PageURLSegment = "PageURLSegment";
public const string PageChildOrderRule = "PageChildOrderRule";
public const string PageExternalURL = "PageExternalURL";
public const string PagePeerOrder = "PagePeerOrder";
public const string PageCategory = "PageCategory";
public const string PageStartPublish = "PageStartPublish";
public const string PageStopPublish = "PageStopPublish";
public const string PageCreated = "PageCreated";
public const string PageArchiveLink = "PageArchiveLink";
public const string PageShortcutType = "PageShortcutType";
public const string PageShortcutLink = "PageShortcutLink";
public const string PageTargetFrame = "PageTargetFrame";
public const string PageLinkURL = "PageLinkURL";
public const string PageChangedOnPublish = "PageChangedOnPublish";
public const string BinaryData = "BinaryData";
public const string Thumbnail = "Thumbnail";

As can be seen, the ContentTypeXX naming hasn't been moved to the database level yet. And I assume Optimizely won't be apply it in the near future either.

It's not a bug it's a feature!

Stupid me!

I forgot i just have to read through thousand of lines of decompiled code to learn about historic f..ups made by architects that should focus on gardening rather than writing software.

This forum is a joke

Ps. next time maybe don't introduce breaking changes into FIRST PARTY PLUGINS by changing names of properties in legacy systems.

Legacy naming may sometimes be troublesome, and Optimizely should fix this. However, it is common that certain entities are named or accessed differently when using various layers of APIs:s or methods. 

Anyway, none of this is a reason to be impolite. Clean up your attitude if you want further help; most of us answering here are not Optimizely employees. 

Most importantly, did your question get the answer you need to understand the data model of Optimizely CMS and its history? 

I don't have issues with legacy code and it's quirks, I have issues with the fact that this change was introduced in migration to 12.

It was FINE in 11 and somebody decided to break it in 12 by making half–assed change. 

Somebody explicitly said "let's f* up this working piece of code".

It COULD be done so much better, or even better not done at all.

But no, from now on every tme new developer will want to use criterion somebody will have to explain why when he wants to use ContentTypeId he has to search by PageTypeId and that ths is GOOD thing.

Ps. telling that somebody that greenlit this change has no idea about proper maintenance of legacy software is not badmouthing, it's stating facts.

...And a forum that says that this is "a good thing" is a joke.