The thing to think about from a DBA perspective is that we're neither fish nor fowl. We're not developers, yet we work with the development teams and are a major part of most development projects and development deployments. We're not sys admins, yet we have to work within the arena of servers and drives and shares and security that the sysadmins deploy. We straddle both these worlds, yet neither is too crazy about having us around AND yet neither wants to do our jobs.

So, for a DBA, it's easier (not necessarily better, not necessarily required) to just have sysadmin rights. I get done what I need without having to bug the sysadmin's who don't want to talk to me anyway. So, a common example from my past. Log backups fail (or, a new database was created and log backups were never enabled for it) and suddenly the drive where the logs are stored is full. It's 3AM. If I have sysadmin rights, I quickly create another network share, map the server to it, add a log file to my database, and figure out how to fix things from there. If I don't have sysadmin I... 1) Call the sysadmin person and tell them 1/2 of what has to happen, right flipping now 2) Cheat by shrinking other log files in order to free enough space to then get the backup of the full log done. Option 2 is actually much more time consuming and inherently less safe, but it may be the path I take because, let's say, in the past I didn't get quick responses from the admin team.

There are several bad examples at play here (why would we let a database get on the server without log backups, don't we have drive space monitoring, log backup monitoring, log size monitoring, etc.), but, you don't have to meet all the bad examples to understand how that 3AM issue (and it's always 3AM) arises. I worked without sysadmin rights for close to 10 years as the on-call DBA. It's absolutely doable. It's just not as easy.