I am in the have-a-firewall camp but then I like watching packets on interfaces
It is not the be-all and end-all of system security but it provides one of many stumbling blocks which may help me in any attempt to prevent my machine being compromised.
You can for example lock a remote box down to traffic on a fixed IP address only. Then you can deal with the box if it seems to be misbehaving or execute your usual security measures on a new remote box.
Obviously you need to open the ports of the services you offer but you can use rate limiting on them as a DoS prevention on those ports.
You can open services on non-standard ports too but a portscan will reveal them - whether or not they are above 1024. So working off a non-standard port might confuse script kiddies but you might want to rate limit the non-standard port anyway.
I unceremoniously drop on ports 135-139, 445, 1026-1028, 1014-1017 and 10144 and 17488 all of which appear to come from noisy Windows boxes. I believe there is a recommendation that one rejects unrouteable with an ICMP Type 3 code 2 or 3 - which is what -j REJECT does. The -j DROP merely drops the packet and I see no reason why I should add to the noise out there.
You can also log what’s happening at an interface rather than simply allow anything in. This may or may not help in tracing a compromise or simply being aware you are being portscanned or experiencing heavy traffic on an unused port.
All that I have read on iptables advises the default policy is to drop and only allow the traffic you want to have happen - effectively run a whitelist - and this applies to all tables. Obviously it is difficult to think of a whitelist on a server but I think you can still deal with some potential problems using iptables.
I am not sure how you would deal with some of them otherwise.