I would say the noisy conditions Joel's test is concerned with are things like putting your engineers in the middle of managers or a call center. When the noise is occasional engineering conversations, I would say this is not what Joel is trying to shield people against.
If these conversations are constant, and frequently not relevant to the developer, then the engineer is in a poor grouping. If they are relevant to the developer and still constant, then somebody needs to figure out what's wrong with the process that there needs to be constant dialog with the developer; who doesn't know what they're doing or what isn't clear to everyone? This is commonly an occurrence when requirements are in constant flux, which is a whole problem unto itself.
There should always be the ability to go heads down on something to get into the zone for a developer though, but for the vast majority of us headphones provide this opportunity when necessary. If a particular engineer is so sensitive to his environment that headphones do not help, or the environment is too cramped for it to be helped at all, this issue should be raised. If you think you'll be too distracted that headphones won't help, be an empiricist first and try it, I've known a minimum of engineers who didn't find this sufficient.
Collaborative environments mean open communication channels; they don't mean people sitting on top of eachother being cramped.
If you find music too distracting, I knew an engineer who would listen to rain all day http://www.rainymood.com/
All of this said, I've worked places that had secluded offices 2 engineers per, I found good engineers who are collaborative will communicate just fine in these environments and definitely don't need the bullpen style cube layouts, though these cube layouts are still preferable to the alternative cube layouts I've found, and are beneficial to teams which aren't all skilled collaborative folks. We don't all get nothing but the best on our teams.