Salesforce.com is a sales, support, and marketing tool. Salesforce expects that things run in a certain fashion, just like any other software; this led to certain design decisions that facilitated those roles but placed limitations within the platform. Consider a few examples and this will become clear. Every object technically has a "name" field, but this field isn't always viewable or editable, depending on the object in question. For example, Cases, Leads, and Contacts each have a Name field, but for one reason or another are simply not editable. Also consider the Close Date on the Opportunity object. You can't make this field not-required, no matter how hard you try. It simply can't be blank/null. There's a lot of business processes enforced by the system that you can't circumvent.

Similarly, there's a lot of reasons why other limitations are in the system. For example, several objects (including the one in your question) might not be Triggerable right now, because they need to perform a code analysis to make sure that an arbitrarily failing trigger won't cause a bug in any of the standard models, views, or controllers that are associated to that entity. When triggers were first introduced, they were supported on even fewer objects than there are today. Since I presume you're not a salesforce.com internal developer, you have no idea what sort of code analysis they have to do just to even roll out a "simple" change like making the Close Date on Opportunities not-required; it's simply not as easy as changing a line of code somewhere. Dozens of modules would be affected by such a small, seemingly innocent change.

From one perspective, you might say that triggers could be supported for all objects, simultaneously, without regards to the type of object. After all, History tables and Sharing tables are no different conceptually than an Account table or an Opportunity table. Surely, the Oracle database engine would allow you to place triggers in any arbitrary table and have them run on the appropriate DML operations. However, it's not that simple, because you have to consider the side effects. What if a History trigger were allowed, and a trigger were written to introduce inaccurate or invalid information into the History table? What if the History logic assumes that it can never fail to commit to the database, and yet it does fail because a trigger calls addError?

The point is, triggers for ContractContactRole doesn't exist purely because they don't "trust" triggers to run on that object yet. They haven't fully analyzed the potential impact and/or had a chance to push up bug fixes that would have to be in place to support triggers running on ContractContactRole. The exact, specific reason you're looking for is only known to a handful of people, and those people might not be willing to answer the question until you signed an NDA (and maybe not even then), because you're treading on the side of needing to know some system design information you're not meant to know (intellectual property) in order to understand the specific "why" that they might provide you with. Even if you called Technical Support or Premier Support, none of them would be able to tell you why that feature isn't supported, and I would know.

I'm not trying to sound harsh, and I definitely apoloize if I come off sounding that way, but I'm really just trying to say that there's a reason why it's not supported, and when they fix that reason, they'll support it. Personally, I'd love it if I could have validation rules and triggers on Contact Roles in general, and even custom fields. Turn it into a full-fledged standard object that is no different than, say, a contact. But I know that they have to analyze the situation, and look before they leap. They didn't design salesforce.com to be the "ultimate" customizable database with UI, they designed it to be the ultimate CRM, and to that extent, they've done a great job so far, but that design path led to limitations.