I absolutely agree except that IS possible to have your cake and eat it too. And that's a great segue into the much more important topic. As DBAs, one of our jobs is to make the data accessible to those that have the need and are authorized to get at the data. That's where the world usually comes crashing down because a lot of DBAs just give the users privs and then gripe about their impact on the production server instead of doing something about it.

To wit, most users don't write truly ad hoc queries. Normally, they've written a query where they go in and change a date range or a department number or some such similar. What the DBA needs to do (and, yes, I do it) is to 1) identify the code if it becomes a performance issue, 2) fix the code and possibly turn it into an easy to use stored procedure, iTVF, or View, 3) get with the user and show them how to use the fix, 4) possibly teach the user why the changes to the code was necessary, and 5) ask the user to submit future code for review so you can help them avoid performance or accuracy problems. A lot of DBAs don't even try to do step 1 and, of those that do, never make it past step 2.

This also gives me the opportunity to again print David Poole's wonderful quote of "If you're the first person that people seek out for database help rather than the last, you might be an Exceptional DBA".