I'd hate this to end up as a slanging match but the main reason many systems work poorly is the apalling design and implementation of third party applications - usually the more expensive it is the worse it is - and because it's expensive big companies have to buy them. If we can train developers properly to understand set theory and database technology we might have better applications. But it keeps me in work as I spend most of my time tuning poorly performing systems.

Just to throw a spanner into the dbcc arena - you must use some dbcc commands otherwise you cannot check the integrity of your database and up to sql 2005 there were some excellent dbcc commands used to diagnose performance issues , umsstats, memstatus, traceon, opentran to mention a few - so if you've never used a dbcc command you're unlikely to be the type of DBA I'd employ - course if you're just a button pushing DBA who never strays beyond the GUI then you'll likely not understand what I'm writing - and this is part of the problem I think - the job title of DBA has become diluted with not any sensible way to differentiate from the developer who's looked after a single server in a small company to a person who manages several hundred 24x7 a "always on" systems along with DR, BCP etc. etc.