First and foremost, the most common reason I see to have poor network traffic controls (on network or system level firewalls) is that defining the traffic ACLs is to skill/labor intensive. You need to have the skills and patience (read: time) to make sure that everything works and you're blocking everything else.
That being said, I tend to design systems to rely primarily on the network level when I can for traffic controls because I reduce the number of possible points of configuration which helps configuration management, auditing, and troubleshooting. If I do want focus on the host I am more likely to use host level firewalls on Linux systems for 2 reasons, 1) the services to be permitted are easier to isolate, and 2) iptables configurations are much easier to archive, manage, and audit (at least for me, I really haven't had much success with any kind of task automation with the windows firewall or ForeFront).
Cloud IaaS can make this complicated, because it's much more involved to employ network or "soft" VM based firewalls, and creating traffic isolation in elastic environments is tricky. The times I've designed for Amazon AWS, I pushed the systems design to Linux, rather than windows (Drupal/MySQL system that was being migrated from a Windows implementation to cloud hosting) partially because of the network traffic controls.
Network security design is not about firewalling everything, it's not that simple and the more things you have manipulating traffic, the more trouble you're buying down the road. It's about defining your security zones (how needs access to what, and how are they getting there), and then determining what controls to use. If, in the OP's instance, it's a web server and DB server in a DMZ that has ingress of HTTPS (443/TCP) and no egress, then I'm not sure that an additional control between the 2 servers buys you too much. The main advantage I see is limiting the depth of exploit if either of the 2 servers is compromised, but given that they are windows servers, and it's likely that they are using SMB/CIFS (137/TCP, 139/TCP, 445/TCP) rather than SQL server authentication, you have to allow all the ports you'd want to block anyway.