To think of this another way, you might not have a problem giving up your Social Security number and debit card PIN number to a bank employee while you're in their office conducting business, but if there were a half-dozen other people in the office too, listening to the conversation, you would certainly think differently.
Up until now, I'd been under the impression that Childs' refusal to divulge the passwords occurred during a private discussion or meeting with his boss -- not in a situation like this.
An apt analogy for this situation might be nautical in nature. While a ship is at sea, the ship's captain is the boss -- no matter that he may be outranked by others on board, he alone controls the ship. The captain doesn't own the ship, but to protect the ship, crew, and passengers, he accepts all responsibility, and in accordance, his word is law.
If you picture Childs as the captain and San Francisco's FiberWAN as the ship, Childs was acting in accordance to that idea. It's not a bad comparison. Childs didn't own the FiberWAN, but he was paid to build, maintain, and operate it. He alone was responsible for the proper operation of the network, and accepted all responsibility for it. It's likely then that he felt that divulging the passwords in that scenario could significantly undermine the proper operation of the FiberWAN, and thus refused to do so. To complete the analogy, you might say that he was on the receiving end of a mutiny, and made to walk the plank. You can't say he went down with the ship, however, since the FiberWAN was fully operational throughout.
Also, who would have received the blame if someone in that room had used that information and caused problems on the network, either inadvertently or by design? Given the technical naïveté displayed by the SFPD and the district attorney's office in this case, it's highly likely that they would have gone after Childs. After all, this is the group that believed he was tampering with the network when his DTIS-assigned pager went off with a notification from "What's Up Gold."
As any network administrator will tell you, the leading cause of network problems is human error. If you limit the number of humans that have access, you necessarily limit the problems. It's not just best practices, it's common sense.