added a comment - - edited
PDT depends on WST, so when you install one it also installs another.
This problem is very specific to WST. For instance, I installed another CSS editor for Eclipse from http://sourceforge.net/projects/csseditor/
It works fine with Aptana Studio, but when installed into WST, WST complains the same way about content types.
If you want to understand the problem deeper, I could explain:
First of all, editors work with Documents which hold file content and additional information.
The standard document class type created by Eclipse internals by default is SynchronizableDocument. Most of the editors rely on IDocument interface, so it not an issue.
WST uses very special type of document, org.eclipse.wst.sse.core.internal.text.JobSafeStructuredDocument which still implements IDocument, so it's not an issue too. But it overrides default partition content type IDocument.DEFAULT_CONTENT_TYPE with WST-specific types per file which all other editors don't even know about.
The way WST replaces default document class with their JobSafeStructuredDocument, it using org.eclipse.core.filebuffers.documentCreation extension, which is deprecated since Eclipse 3.2. See http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Ffilebuffers%2FIDocumentFactory.html and WST code at http://eclipsesearch.appspot.com/pluginXml?name=org.eclipse.wst.css.core
This documentCreation extension relies on contentTypes. So we had to overcome this by placing Aptana's CSS file content type for Aptana Web/PHP/Rails projects first.
So if you wand to use WST editors in full, I already posted the workaround above, which is "Remove Aptana Web nature from the project". The effect will be that some features of Aptana Studio editors will not work.
Aptana Studio 1.5 worked in a very different way regarding document partitioning and scanning. Basically it didn't use standard Eclipse partitioning capabilities, and so had a set of other issues and limitations.