2) The computer is assumed to be administered by people who make mistakes from time to time; in such a situation having a firewall by default serves as an extra step that "nudges" the administrators to revisit their assumptions and intentions: "Now that your httpd/database is running, did you really want it accessible by the net, or only by localhost?" With this assumption, a firewall should be present, and blocking incoming connections by default; it makes sense to make it fairly easy to enable access to a service after setting it up.
3) The computer is assumed to be running on a non-homogenous network, e.g. providing some services to an internal network and fewer services to a public-facing network. It is unsafe, or at least risky, to expose internal-only services on the public network. With this assumption, a firewall should be present, and blocking incoming connections by default; the system shouldn't be enabling access to a service after setting it up, and leave this to manual administrators' action (unless the system understands how precisely is the network non-homogenous).
4) The computer is assumed to be already compromised, or highly likely to be compromised. In that case, a firewall blocking incoming connections by default would stop
some communication, but it makes
almost no difference: Instead of opening a port and waiting for an incoming connection, the attacker can make an outgoing connection, which is not restricted by the usual firewall setup. Because most home routers doing NAT implicitly act as firewalls that block incoming connections, it would be almost
unexpected if the attacker tried to open a listening port nowadays. Overall, I don't think the firewall is effective in this scenario in most cases, so this scenario doesn't matter in the discussion.[2]
, and are mutually exclusive; it doesn't make sense to treat one set of ports differently from another. This is the reason for my objections to the suggestion that the default setup of the firewall should differ between roles.