Compare that to the weeks and months that marketing, product management, development, QA testers are working on features and it is insignificant.
Where is all of this development and QA testing going on? The point of a cloud is to build and automated image that can be deployed to any of your environments. Presumably you are architecting your applications so that they scale as well which the cloud is excellent for.
For example the dev team is done with their changes and want to push from the dev environment to UAT. Say you have two instances in UAT. instead of shutting down, updating your code, starting up each machine one at a time you just deploy 2 new instances. The deploy script fires off a test or two to make sure that the app started successfully. If you are doing something web related it hits the API on the load balancer to add the new nodes in, maybe fires off a couple of tests against the VIP, removes the old nodes, a couple more tests against the VIP, and just like that your deployment is complete. If you are doing something messaging related where your services communicate over a message bus of some kind presumably your apps just connect themselves. QA can then test, and determine if the code is ready to promote to production.
Of course this all sounds a bit over complicated for a UAT environment, but once you have every single piece of the puzzle automated that is when things get interesting. Lets say that your source control allows you to mark your projects as "ready for UAT", and allows your QAs to mark them as ready for production. You can just have your entire test system rebuild itself every day and production releases once a week through the same process. Also since you are in a position to scale either through your load balancer or a messaging bus you can use the same processes to scale.
Say your monitoring service watches CPU usage on your web app servers, and as soon as you hit 75% it fires up another instance. If load continues to come in after the new node is online then fire up another one. If the CPU drops below what is required to run on n-1 nodes then hit that load balancer API take a node out and destroy it.
Even if you don't need to scale doing deployments often means shutting down apps on one node at a time. If you design everything for n+1 nodes that means that during your deployments you are still running fine, but you are "at risk"
From a sysadmin perspective this is all great because a machine going down means nothing. Your monitoring services see that the VMs are offline, and they fire up another instance wherever there is extra CPU cycles. Without a "cloud" this is easy to do with VMware as long as you have shared storage, but do you trust the VM? It died while the system was running what if something was corrupted? With the cloud you don't care about the old instance, just let it die. Create a new one instead.
Everyone loves VMs due to live migration but why not take that one step further to save yourself some money while you are at it. Skip the extra cards/ports/networks/switches/cables for iSCSI/FC, skip the expensive SAN and pack the hosts with some cheap SSDs. You don't need to migrate when you can just redeploy (although many of the hypervisors support moving images without shared storage now). This way you get local read/write speeds which will probably beat any SAN that you don't have to sell your first born to buy.
Backups also become much easier. Backup the images (which won't change often), and the source control systems, and you are pretty much set (maybe a couple of 1 off monitoring and deployment servers). Why bother with expensive dedup/compression appliances when you just have a few images to backup. DBs are an obvious exception there.
Speaking of DBs lets say you want to rebase one of your lower environments off of a higher one. Lets say you want to refresh the dev DBs with the test DB data. You just hit the api and take a snapshot of the test DB data image. Clone the that snapshot to a new image, shutdown your DB node, unattach the old image, reattach the clone, and start it back up. All of which can be an automated process. No pestering the DBAs to do it for you.