Each contract type (fixed price, time and materials, structured deliverables, etc.) has its own merits and drawbacks. It is counter-productive to arbitrarily favor one of the other. Given the variety in the needs and capabilities of various teams, one shouldn't even make a general conclusion about what suits the enterprise or projects within the enterprise. The needs of each project deserve review and consideration.
The issue isn't about using a given contract type....it is about using contracting options available well (or poorly).
Fixed Price agreements have an appeal in that they appear to keep costs under control but they don't automatically suit the needs of the contracting organization or its stakeholders. .
Fixed price contract may also have fixed delivery dates - this forces any flexibility in the system development wholly into the scope. This is not always to the advantage of the contracting organization because many project offices are challenged to bring to bear the technical management and engineering resources necessary to manage this dimension. In fact, I have often seen vendors take the "upper hand" on many project releases because cost and schedule are fixed....and the vendor often is in a position to bluff, cajole, or otherwise convince the contracting organization about what scope will fit.
Fixed price is often asserted as a cost containment method but that can be deceptive. It truly provides a mechanism to avoid the number of dollars going out the door from being more than agreed to but that doesn't necessarily contain true cost. Since fixed price aggressively shifts risks to the vendor, their bids are necessarily high. You won't end up paying more than the contract price but the contract price may be inflated. Also, fixed price shifts flexibility into schedule (sometimes) and scope (usually). Vendors can be adept at getting the contracting organization to accept shifts in scope under fixed price. When you pay the same for less functionality, you've still had a cost over-run.
But procurement offices often favor FFP contracts because they are easier to administer for them and they are responsible for the administration of the financial paperwork....not often held to task about the functionality of the systems built. It is only a slight exaggeration to assert that a project can spend millions, deliver nothing, and procurement won't feel any heat at all as long as the payments made properly and the bookkeeping adds up.
Where FFP works better, and the contracting organization more often gets closer to its money's worth, is in the "rack and stack" IT work (e.g. setting up LAN equipment for new office space) but not so much in application development.
Fixed price mechanisms also work well in various forms of out-sourcing - e.g. if the organization currently pays so much for lock-box operations on a per transaction basis and is shopping for an alternative or additional provider. Still, you have to preserve mechanisms to sustain the quality of operations. For many organizations it would be better to have a modest cost over-run in development or operations rather than have dis-satisfied customers take their business, and money, elsewhere.
It is more advantageous for contracting organizations to have some flexibility in the time and cost dimensions. This is especially true in projects likely to have "last-minute" changes.
In my experience, what are often called "tiered" or "structured" would probably fit well for most enterprise modernization or business development systems. They often are a better alternative or variant to fixed price and this is my starting point in most IT contract work. These arrangements give the enterprise some flexibility to scale up, scale down, or replace work packages.... but in a more deliberate, pre-planned, manner than would occur under time and materials arrangements and also keeping various responsibilities upon the vendor.
A good portion of the relatively well-run projects I've worked on have favored these "structured" type of arrangements and that is why, at least as a starting point, I favor them as in the interests of the contracting organization much of the time.
Finally, time and materials contracts are often maligned but really work out well for some organizations. Places that have the management and engineering talent to run their own projects often do well contracting out lots of the building - hardware, software, etc. Places that want to have tight control over their intellectual property favor and often use these mechanisms well.