You'd be right if we were talking about an iterated prisoners' dilemma (i.e. hiring the same contractors over and over.) It'd be bad management to be in an adversarial relationship with people you maintain a consistent relationship with.
But the point of Mechanical Turk is to gain a scaling advantage by designing your task as a non-iterated prisoners' dilemma (i.e. so that arbitrary new untrained people can come in and do one of your tasks once, and then not necessarily ever interact with you / your tasks again.)
This requires a very different mindset; one that not many people possess. Even most of the people who are using Mechanical Turk "successfully" don't design their tasks to actually be reliably accomplished by the firehose of arbitrary new untrained people that come through the service. Most employers on the service just use it as a temporary-worker recruiting platform — using work-sample test tasks to cull down to a set of reliable workers, and then feeding real tasks to only that pool of pre-tested workers.
But this throws away the key advantage of Mechanical Turk — the scale and elasticity to demand you get by being able to rely on "literally any human" to complete your tasks, rather than needing to be filter them down further and thus expose yourself to winnowing (which is especially harsh in the MTurk world — no worker on the service stays with it for very long, as it's one of the least marginally profitable things you can do with your time, only worth it if you have literally no better options. And most people find another option fairly quickly.)
It's not every task that can take advantage of "literally any human" — but the workloads that can are far more numerous than these tasks' designers think. They just don't understand how to create specs that stand up to an adversarial implementation.
Designing tasks for MTurk is, essentially, writing a wish for a malevolent genie, such that you can automatically verify whether you got what you wished for, and such that you can prove to the malevolent genie that that verification step is what's going to happen, such that they have no reason to defect. It's the baby brother to the AI control problem.
A good example of a well-designed MTurk task (if it were implemented as one) would be Google's older implementation of reCaptcha, the one that shows the "worker" text from books / street-view street-facing signage, and gets them to write what they see. The whole "present one known and one unknown" and "cross check inputs across several workers" parts of the design are there to allow the system to work in a non-iterated prisoners' dilemma context.