First of all, I'm in the camp that thinks this is a terrible idea. Security is about trade-offs, usually trading potential safety against convenience. But in a business environment it's all about costs. The cost of a potentially malicious outside influence in your source code (which is dubious at best) would have to outweigh the increase in development costs, which will be dramatic.
The cost of security failure isn't an all-or-nothing game; you can mitigate the cost of security failure by using proper vetting, backup, code review, and SCM techniques and tools. Plus, these techniques help with other issues as well, not just security problems.
The only excuse for such a policy would have to be a gross understatement of the costs it would impose and a lack of understanding regarding the alternatives. And a company with that sort of management disability is not a good long-term employment prospect.
Now, that said, I can think of one environment in which such a policy is perfectly reasonable. Specifically, many security-related companies (and government security contractors in particular) have a red-green division on all resources. The "red" side is susceptible to outside influence, while the "green" side is absolutely isolated and self-contained in every way. No cross connect, no shared systems, no shared code, no shared information.
In such an environment, "green" development would have to happen on a machine that is disconnected from the Internet. However, also in such environments, each employee/developer is expected to have two workstations, a red one and a green one, so the empoloyee would not be utterly cut off from the Internet.