First, let me state that I'm a developer, not a DBA, so obviously I'm biased 😛

In the company I work for, DBA responsibilities are really spread out all over the place. Developers actually build pretty much all new database objects (tables, procs, etc etc), but the systems are reviewed by the people that will be supporting the code as well as "real" DBAs (but not in all cases if I'm not mistaken). In my opinion, we wouldn't be able to do our jobs as developers if we didn't have this freedom. Now I'm not talking about the QA, Staging, Production environment, strictly the true TEST environments.

I frequently talk to some friends in a sister company that have what's considered the DBA's dream. ALL database servers are completely locked down. If a developer needs a new database object, they request it and might see it days later if they're lucky, not because any PERSON is slow, but there's a lot of red-tape (prioritization, etc). This is EXTREMELY frustrating for the developer who has to hurry up and wait. I should mention that developers are locked out of more than just dev database servers. ALL dev servers are off limits. Now I undestand they're finally allowing the devs to us VMs at least, but in my opinion, although that protects the precious dev servers, it simply makes what the non-devs would consider the dev servers simply an extra, non-dev layer of servers between the REAL dev (the VMs) and production, and therefore completely unnecessary (expensive and completely wasteful to maintain).

I suppose the devs in my company probably have a lot more database background than the 'average' or 'pure' developer. Shoot, I read and occassionally post to this site afterall. To sum up my feelings on this topic, I favor letting devs take a stab at creating DB objects and guiding them when they do something horrid (and we do all the time). Like others have said, we won't learn anything unless we try it ourselves. And I know every project is different, meaning there is no 'right' answer. But for that reason alone, I believe that the always-devs-locked-out-of-dev-environments approach is wrong at least some of the time (if not the majority of the time).