If this were the 1990s, this would be the perfect answer. Back then, the idea was that you use a firewall as a perimeter defense in a defense-in-depth strategy.
But this isn't the 1990s, this is 2014. Nowadays, you have to assume that at least one endpoint on your local network is compromised in some way, whether that be via malware infection, clueless intern, corporate espionage, disgruntled employee, etc.
These days, any decent firewall does a lot more than prevent access to ports -- most actively monitor the traffic passing through any open port, and when configured correctly (in this case for a DB server), they'll lock anything down and flag that doesn't look like a SQL transaction, and then check for common SQL exploits, for connections to network points that should not have access to that port, for binary objects being passed in the SQL queries, and more.
What this means is that if you consider a firewall to be enabling the Windows Firewall on your MSSQL Server/Windows Server 2008 box, it's probably a good idea just because those boxes are usually not locked down correctly, and someone could be browsing facebook in IE on that box unless the firewall prevents it. But this isn't really the sort of firewall you should be applying to a transaction server that may one day have to be PCI DSS compliant.
See https://nakedsecurity.sophos.c... for one case study of how things can go horribly wrong incrementally.