Right. I would rather fix the broken developer once, than paper over systems with a firewall. Perhaps I'm too idealistic. (IMHO proper devops does this - helps give devs a proper view of system administration by sharing knowledge and responsibilities).
I'm also pessimistic enough that I think allowing development to install back doors (eh, "useful helper daemons") willy-nilly in production systems is a bad idea ;-)
Who said the devs have access to the production systems? :) You can still lose valuable information with the loss of a testing server.
But you're acting as if you know which dev is the one who is going to do 'it'. I'd rather have a firewall that is largely set-and-forget than keep tabs on teams of devs that go through hiring cycles. There's already enough for ops folks to do without having to psychologically evaluate developers... besides, I've been through a few devs who agree sincerely not to do $bad_thing, and then caught them a few days/weeks/months later doing it again.
It's sad, really. I'm not even a security zealot, but I have overheard the folks in my small company tell each other not to let me know that they've signed up to a SaaS with a weak password (company name + digit).
Oh, I suspect all devs, I just think a sound process around small, cross-disciplinary devops teams is the preferred approach.
I get that a firewall can sometimes help fight broken practices (eg: bind on all interfaces, no password by default). But if your devs end up deploying password auth in general (rather than key/cert based) - with weak passwords in particular - your firewall is unlikely to help in the case where a service is supposed to be exposed.
I'm also pessimistic enough that I think allowing development to install back doors (eh, "useful helper daemons") willy-nilly in production systems is a bad idea ;-)