Deployment Manager Vs DBA Cage Match On Pushing Releases To Prod
Firstly, every environment is different. What works in my environment won't automatically work in yours. (We = DBA Team)

In mine we have the following environments for this process

Dev - Normally we restore a copy of live in preparation for a release and sanitise data as required. We then back that up and enable the dev to restore to that backup at will. They then prepare and test their deployment scripts. We expect the Devs to have tested the upgrade/release process in full successfully before it needs to go to UAT. We will often be required to help and advise at this stage

UAT - Again we would restore the copy of live and sanitise (if we are going to use a QA environment). The release and config manager then provides us with the correct scripts for the upgrade from the developers and we will check them, run them whilst monitoring to be able to provide all info required for CAB regarding loss to service, time to upgrade and any changes required to maintenance/monitoring scripts which we then advise the Release Manager.

Sometimes we use a QA environment, usually when sanitised data has been used in the two environment above and the business are required to QA rather than the test team.

CAB - The Release Manager provides all the information for CAB to make their decision from the proceeding steps to lay out exactly what happens during the release. They are also responsible for storing the scripts used to go from Dev to UAT and providing them to us for release into live. We only use the scripts provided by the Release Manager and referenced in the CRP. We obviously check that the scripts are the same as the ones we used in UAT as I am ultra cautious

Live - We deploy to live exactly following the steps in the Change release Plan authorised by CAB, often co-ordinating with other teams 

The reason we do it like this is partly as it is the process that we have to follow here (Using CAB etc) but in answer to your question it is because the DBA team are the ones responsible for the safety and accessibility of the data. Also because we have the skills, knowledge and experience to recover from unexpected problems. What happens to the Live databases is our responsibility and we take it very seriously. No-one else is allowed to perform tasks on the live databases other than the DBA team. We are the guardians and the bouncers (door men/women)

For your update. I bounce that sort of issue back to the developers and require them to fix it before I deploy to UAT. Once the script is finalised (at UAT) we know it will work in live.

For your another example - That is the job of the release manager. If they are providing us with scripts that fail we bounce it bak to them and require them to fix it before we will deploy into UAT. We WILL NOT deploy into UAT anything that requires bodging or changing from the instructions provided and in the few occasions wen this has happened (a developer used the app account to manipulate some data after we had run the scripts to enable the release to pass UAT) I stand up in CAB and explain this and explain that I am not happy to release this to live without a correct test of the release. This usually works :-) I know I am harsh but I am also fair.

I tell the release managers and the devs that the process of passing the release to UAT is the test not only of the release but of how the release will be performed therefore we will follow the exact same steps in both examples (dev - UAT and Live) and that if it fails in UAT it goes back to them to fix.

I hope that helps