From my perspective I'd say understanding the context of the data you're manipulating allows you to see the bigger picture. However I'm a bit of a mongrel.

Choosing the right tool for the job is possibly not as important as reducing the complexity of the environment though. Tacking yet another "best in class" solution on every time you want to do something new is surely not the way forward (for a start how do you know it is best in class if it hasn't been around for 10 years, it's probably just another piece of cutting edge buggy crap). For me - there isn't much of anything you can't do with your business logic in TSQL, I'm with Jeff.

As to knowing bits about other aspects of the architecture - of course you need to understand a bit about the OS you're sitting on and the authentication systems surrounding it.

Perhaps how puritanical you are about this questions depends more on your environment than anything else - if you're looking after 50 databases for a company you're going to be spending an awful lot of time examining log files and query execution plans and doing not a lot else, if you're looking after 5 you need to spread out a little...