I work at a government agency, no scrum, no agile, no nothing. It's so bad I'd kill for waterfall.
I personally love Visual Studio. Using continuous integration was an eye opener to me, I'm still not sold on continuous deployment though (on call isn't a good option IMO for a developer).
Infrequent deployments don't prevent on-call scenarios. Stuff can and does still break between deployments, as external dependencies change, load increases or it's characteristics change, "time bomb" bugs go off, or any of a huge number of other things happen. Infrequent deployments mean that responding to these events is slower and more costly.
Infrequent deployments also greatly increase the risk of problems during deployment, because infrequently exercised pieces of code (i.e. The deployment code/scripts) are more likely to be buggy, and because gobs of changes pile up between deployments.
With that said, continuous deployment probably should not be happening at night or on the weekends unless you have rock-solid automatic rollback and the necessary monitoring to trigger it.
I think the idea is that continuous deployment is like working out a muscle. At first it is way more painful that the status quo. But over time the muscle (deployment team/system) can adapt to the workload and become stronger.
But it only works if you have the time and resources to react to what happens. For example if you find out that differences between dev and prod servers can cause problems, you could add a tool like Chef/Puppet/Ansible to prevent those differences.
But if you don't have the time or resources to invest in that sort of change (as in many government agencies), then continuous deployment will just pack more problems into a shorter period of time.
This would be analogous to lifting weights, but never getting enough sleep or good nutrition. Under those circumstances, a person will just get weaker and more injured over time.
I personally love Visual Studio. Using continuous integration was an eye opener to me, I'm still not sold on continuous deployment though (on call isn't a good option IMO for a developer).