In most places I've worked, wfh was an essential option that helped avoid long commutes, allowed me to take care of personal business (like the dentist or picking the kids up off the bus) and allowed for some sanctuary to code. Some places I've worked used this mode so often that you never had a clue if someone was in the office or at home. This is because they used communication tools so effectively like skype, webex and slack to name a few. There are some other tools that are often classified for project management, which were equally essential for communication - trello, jira or any flavor of kanban. And this is one of the key reasons why wfh was even possible. For those businesses that don't have a work from home policy or, in worse cases, strictly forbid it, they have some catching up to do to remain competitive in the market place. I've turned down plenty of offers for this very reason.
Companies that don't have a wfh policy often manage their workforce by the duration that their workers occupy their seats, with stringent hours or even such policies as unpaid lunches. These desperate actions are in place because the employer is measuring the wrong thing with the wrong tools. Measuring work input seems like a sensible approach, but it creates incentives to work less efficiently, because there is no incentive to succeed or complete work. On the other hand, measuring output turns the focus on what's getting done and ignores how that happens. Should someone have an inspiration in the the middle of the night, they can go work on that to their heart's content. If they are measured by time, there is little point in thinking on a project off hours.
When you begin to measure by stories completed, as in a burn down chart, or monitor the rate of check-ins, you can start to manage to the finish line. The workforce starts to look like a sprint team, as opposed to a bunch of out-of-shape 6th graders, dragging their feet around the track in gym class. Techniques like paired (or mob) programming become an option, because we don't consider two people working on one task as halving our effort, but raising the overall quality of the code. And as the code quality rises, fewer defects are created and the total cost of the code goes down. Skills and techniques are transferred so the team as a whole becomes more effective and the cost of future projects drop.
So why would I turn down a job that has no work from home policy? Clearly it's a more oppressive environment that shuns learning and sharing and smells of desperation and defeat. I think anyone would.