In my experience this is a huge productivity killer for engineering teams. No, sitting us down next to the recruiting guy doesn't make the recruiter better at technology or the engineers better at understanding recruiting. It mostly just makes us hate the person who talks on the phone all day while we're trying to work.
As an example, In video games this is used as a way to get a feature shipped. Plop a bunch of artists with a coder or two and a couple of QA guys and roll a feature together. It cuts communications time, keeps everyone focused, and as long as your feature is encapsulated nicely it should merge back cleanly into main in a few days.
If you are just applying a blender to the org chart it isn't going to be a great choice. However, something like putting a developer within ear shot of Technical Support isn't always a bad idea.
At the studios I worked at, these were called "meetings."
Having a developer spend a day with the support team every so often is a great idea. Putting them within earshot just leads to the developers wearing headphones all day.
In my first job, We had separate infrastructure and development. Infrastructure had DBAs, Sys admins and specialists in random tooling, but nobody could code to save their lives. I managed to get myself sitting with infra, and not only I learned things that back then they'd not share with application programmers, but I could use my programming skills to deal with a lot of low hanging fruit. Today nobody in their right mind would train someone to know SQL and DB administration and know no general programming at all, because of how much power you lose by not coding... but there, it was a life saver.
At my next job I spent time programming from the back room of a retail store, stints in warehouses, and even with accounting. Then I could not just write code for them that made more sense, but even keep their goals in mind when working at a project with someone else.
At another job the company was doing heavy waterfall. The project I landed on had been going on for 2 years, but no developer had EVER talked to anyone in the user's department. It all went through business analysts and project leads. Needles to say, the internals of the system had nothing to do with the user's mental model, and the business analysts, which had no special training, were designing screens and answering questions, while they were badly informed. I used a fortuitous maternity leave by one of the leads to just spend a few days a week in another campus: One that had people that were not my users, but understood them far better than any analyst I had, and broke all protocol, redesigning some pieces of the system. When management came back, I told them that I wanted to show my changes to users, and they were ecstatic, as the changes were right on. A month later, my team was embedded with real business units, and management decided that, since we had better results than anyone else, that we could get away with not doing waterfall. All because I actually cared about what other people in the company were doing.
So sure, if you are sitting next to recruiting in an open office, and recruiting doesn't go into any closed booths to take calls, it's probably not so productive, but I have never worked at a place where getting to know what other departments are doing didn't multiply my chances of having more impact.
However, what I think I am great at, is making non-developers understand what it is I'm doing. I think this is a real skill, undervalued on a lot of teams. For this reason I actually enjoy and am more productive sitting next to the sales/AM/PM cohort. I like being tossed questions re: scope/SOWs because I know it'll pay dividends down the line when the team knows that a number was vetted before going out the door. I like it when I can explain why it's not a quick job, and they understand, and more importantly they can make the client understand. But I also understand that this isn't a role a lot of devs are comfortable filling - and they really, really shouldn't be forced to.
Now, you could argue none of this would be necessary if the team/agency/company had proper systems in place - and you'd be right. But I've yet to work for an agency that had it all figured out.
I own/tenant a small co-working space and we try to filter out the types of freelancers and small businesses who need to take or make an unreasonable amount of calls that might distract others. Surely Stripe would have considered this sort of basic open office stuff.