This sort of thing varies hugely from place to place. At my current site, the line between developers and DBAs is very blurred indeed - we (DBAs) write PL/SQL too, and they (developers) dissect query plans. We all see ourselves as peers, merely with different skillsets and responsibilities. This is very amusing: recently the company has jumped on-board the DevOps bandwagon. The database community don't understand this at all; we've always worked like that. Needless to say we are enormously productive working like this: the database tier is by far the most reliable part of the company's technology stack, it's easy to operate (since we have the skills in the DBA team to understand the application at a deep level, and the developers have the DBA exposure to understand 24/7/365 operations and how to structure their apps for it).
But I know what you mean when you talk about the "wrong" sort of developer. He's self-taught, which in and of itself is a noble thing, but along the way he's picked up a distrust of any sort of formal instructions. He doesn't know what he doesn't know, and he resents anyone trying to enlighten him, he sees it as an insult to his self-learning skills. He's learnt the imperative style of programming, because you can learn it without any of that theory stuff that CS types are always babbling about (well, badly; everyone needs to know big-O and similar bits of theory). He's learnt a bit of OO too, just because he has to to use Java. But a good database professional - developer or DBA - has to be comfortable thinking in a declarative style, thinking about set theory, normal forms, even being able to understand the relational algebra and calculus. It's very, very difficult to communicate with these people, because they are actively hostile to anything that might jolt them out of their comfort zone, which is by and large confined to how to format something on a web page. If they think about databases at all, they think that a table is like a class and a row is like an object. These guys will literally just do
SELECT * FROM TABLE and filter and sort the results in their own code. They really, really don't understand why a database is better than a flat file (and they not-so-secretly think anyone who uses a relational database is an idiot).
Let me give you a real example: recently I was talking to one of these types about the issues involved in rolling back a release of our software after it had gone into production, if an issue had slipped past QA. I explained that while we might roll back his application (one of many accessing the database), it would need to be able to operate with the database still deployed. He asked why, and I said, well, in those new tables and columns, there will be real customer data. He then said, so just copy it into a temporary table, what's the problem. I stared at him in disbelief: when a customer calls and says, my money has disappeared from my account, what do we tell him, that it's OK, it's in a temporary table? He simply didn't get that when you are dealing with other people's money, you have to act like a responsible adult. For all I know he still doesn't; he's no longer with us.
The MySQL camp were like this for a long time; they would say you didn't need transactions, foreign keys, etc, if you thought you did it was only because you had no idea what you were doing, etc, etc (then when they grew up, they quietly added them in). These are the kinds of people ORMs like ActiveRecord or Hibernate were developed for, so they could write database applications without ever needing to touch SQL. Use of these technologies I consider to be a red flag - this is not a company that values DBA skills. What they really want is a babysitter...