There are multiple reasons, and here is one of them:

Imagine yourself as a boss. How would you check whether your employess are doing the stuff you pay them for, or just taking your money and slacking? (Because there are many people who would enjoy the opportunity to take your money for nothing.)

This depends on the work. Sometimes the outputs are easy to measure and easy to predict. Suppose your employees are making boxes out of cardboard. You know how many boxes per hour can the average worker make, so you have a simple transformation of your money to the number of boxes produced. If someone does not produce enough boxes, they are either incompetent or slacking; in both cases it would make sense to replace them with someone who will produce enough boxes.

This is the type of work that would be safe to let people do remotely -- as long as the same amount of boxes is produced, you get the value you paid for -- although there may be other reasons that make it difficult: transportation of the cardboard and the boxes, or maybe if a machine is needed.

But imagine the kind of work like software development. To the eternal frustration of managers, the output is hard to measure. Both because of inherent randomness of the work (bugs appear unexpected and may take a lot of time to fix), and because the people who supervise the work are usually not programmers themselves (so they have no idea how much time "writing a REST controller which provides data serialized in XML format" should take - are we talking minutes or weeks?). Different people have different strong opinions on what quality means, but it is a fact that some projects can grow steadily for years, while others soon collapse under their own weight.

Having this kind of work done remotely, how do you distinguish between the case when the employee solved a difficult problem, fixed someone else's bug, and spent some time preventing other bugs happening in the future... and the case when someone did some quick and dirty work in 2 hours, spent the remaining 6 hours watching Netflix, and afterwards reported 8 hours of work? Trying to impose some simple metric such as "lines of code written per day" is more likely to hurt than help, because it punishes useful legitimate work, such as designing, or fixing bugs.

Making the people stay in the office guarantees that they will not spend 6 hours watching Netflix. They may do good work, they may do bad work, or they may find ways to procrastinate (e.g. watch YouTube videos instead). But at least, there is a long list of things they can't do.

It seems like a problem of trust, but on a deeper level it is a problem that you can't even "trust but verify" if you can't actually verify the quality of the output. So you have to rely on things like "spent enough time looking busy", which sucks for both sides.

-