That's slightly self-centered. Nobody cares about you or their co-workers so much that they are offended if you don't want to work (or bask) in the team's presence.
People are tribal by nature, and one of the ways humans feel a sense of belonging is through overcoming common conflict (i.e. Tuckman's stages). While not impossible, it's much harder to have common conflicts if you're just not there.
People were tribal before communication tech.
That said the company success will depend on how frequently the information can be mixed up. That said, some roles do not need as much communication as others, especially in mature business and niche positions.
our entire team is remote. it's really obvious when someone isn't at their computer. it's basically the only hard requirement of the job beyond the work product - be at your computer when you say you are going to be at your computer.
For example, "water cooler" conversations. In a physical office these happen because people are conditioned to make small talk. That is not the case virtually, as it's easy to spend an entire day in a chat room with a co-worker and never interact with them.
I remember doing a quick fix for one of the attractions at the melenium dome - the core part of the work was working out on paper all the permutations and what should happen the coding at a terminal was the trivial part.
BTW the program correctly run first time and was delivered in less than a day.
It's the same reason why almost every company programs in blub vs. lisp, haskell, erlang, etc. The skill level of employee can be hard to find who can do those things. Companies already feel supply constrained with engineers, now imagine you add the haskell requirement and you need to hire 1000 of them.
Startups can leverage this disadvantage sometimes by not having a statistical management requirement and start with a foundational advantage. There is also the case of using haskell killing your startup although because of tool problems, and big companies being able to make small special R&D type teams that can use Haskell, so it's definitely a balance.
As a remote worker I actually want to have this routine, meet people, this is why I go to a coworking space.
The benefit of remote work is that you can have much more choice in the company you work for, without having to move to SF/NY/London/Paris/<some other crowded and overpriced area>.
That would be true if most companies allowed remote work. In my experience, only a few do. Even fewer have a "remote first" culture, where you don't miss important discussions if you're not in the office.
I guarantee that the company that can scale up effective remote working that has severed the tether to co-located organizational structure will be wildly successful. Unfortunately, I think it will also have major social repercussions similar to the impact that autonomous transportation has the potential for causing.
eg.
$10,000 in gross profit - 20% in taxes = $8,000 net profit
$10,000 in gross profit - $1,000 rent = $9,000 - %20 taxes = $7,200 net profit
The net rent was $800 instead of $1,000 but not free.
Those are not necessarily solely financial incentives, but they function to compound and combine with already established systems of corporate organization, personnel structures, and general status quo operations and processes. In that scenario, the co-located work paradigm was not only supported and strengthened where remote working was not, but it also set an expectation that thar be government breast milk in tumultuous times.
I am no corporate tax, accounting, or financial expert; but what I can say is that it seems to be the forest that can't be seen for all the trees.
Aside from that, hangouts, lync and the like do make communicating remotely very nice. I've wanted for years the ability to actually share a project session with someone via Visual Studio (or something similar)... so that you can work in the same visual space... if you're on the same file, you can see eachother's edits/changes real time... if you're in other files, you can just flow...
I don't think it all requires that people be in physical proximity, but there are advantages to being a closer team. I often find that 3-4 developers in the same room can dramatically outperform teams that are disconnected from each other. But then again, I think that if your project can't be distilled into units of work/services worked on by 3-4 developers you're doing something wrong.