When you have a full-time employee, from the perspective of the company you're entering into a contract where you have a fixed cost to buy fixed amount of hours per week of said employee work. To get the tasks completed efficiently is the employee manager's job (set goals, create an environment, give specs & etc...)
When you hire a contractor/freelancer you can pay for output, not time. You can specify the work, split into deliverables and tie the payment to delivered work. This might be more efficient for some types of tasks.
This is on top of all the usual big company politics, planning & budgeting reasons.
That's why I said "may", not "will".
I hire a lot of contractors and if we can't specify the work sufficiently then we don't hire them. Or hire on a fixed budget to get the correct deliverables specified (if possible).
When you pay for "hours worked" the incentive is to "work more hours", not deliver the result. I've seen many employees spending their employers money for such "contracts", but they will not have done that with their own money.
When the task is so hard to define/specify/design, it's not a good fit for contractor's work.
BTW, the building industry has been working with contractors for ages and their practices are very efficient and the IT sector will learn from them sooner or later.
There are two different types of contract. But it's hard for most companies to do 'pay for output' because they aren't capable of specifying the output. And contractors don't want to do it because then they are taking most of the risk.
When you hire a contractor/freelancer you can pay for output, not time. You can specify the work, split into deliverables and tie the payment to delivered work. This might be more efficient for some types of tasks.
This is on top of all the usual big company politics, planning & budgeting reasons.