I think the communications skills versus technical skills and apples to oranges comparison. It's why I separated out the differences.

I've come across hundreds of 'DBA' whom I do not consider a 'DBA' and more like a 'SQL Developer' or a 'Jr. DBA' and that is a matter of technical knowledge, a lot of people know a lot of very specific things about writing T-SQL, etc. However, time and time again, they can not solve problems no matter how much of a people person they are, and no matter how much about SQL though know either. I think databases are unique in that unlike the Cisco guy who only needs to know enough about servers to setup networking configurations or the SAN guy who only needs to know about disk performance and protocol performance, or the developer who only needs to know how to code. The databases administrator needs to know Programming Frameworks and Programming Language Architecture, Basic Programming, SANs, Networks, Protocols, Servers, etc. Who's going to catch the environmental problem of connection string fragmentation? The DBA. Who's going to catch the web pages that 'accidently call for an image 3 times instead of just once?' that QA let slip by? The DBA. If you're running EMC SANs and not paying for all the additional software packages for monitoring, who's going to catch the disk contention? The DBA. Even when it is a database issue, let's say you have some queries timing out? Sometimes it's not the query or the indexes, sometimes it's the system configuration, ever check the sys.configurations? Do you know how to calculate throughput of your disks and your network? All those CX_Packet waits? Did the guy who setup the system leave hyper-threading? on because setting MAXDOP=1 isn't the best solution. This is on top of the database platform specific knowledge that you need to be a master of.

Now this is the minimum. The requirements, the skills required. The most important 'Skill' is a technical/gear head jack of all trades. You are not a DBA until you are in my book.

Then comes the soft skills. To be a great DBA to be able to do all this and explain it to management and end-users in a way that makes them happy. To be invited into the C level meetings as a representative of your CTO explaining how you have a 99.999% uptime, have not last a single second of data, and your thru-put per dollar is the best in the industry, and where your competitors were all compromised, your systems were not and if marketing wants to leverage that information have at it. Now, you went from being a DBA to a great DBA.