A few simple examples.
1) Deploying new code? Spin up a new server behind your load balancer with the new code. At this moment, you have both the old and new code live, so everything needs to still work with both versions out there. This requires extra work. Then you can take down the old server running the old code.
2) Updating a database schema? Fork the database, apply the schema update to the fork. Ensure writes can be applied to both the old and the new schema. Update your code to read from the new schema. Remove the old database schema. Again this process requires extra work.
The analogy for this is "changing the tires on a car while driving down the highway". It's easier to pull over and change a tire, but you could find a way to change a tire while driving if you really needed to.
Amazon's infrastructure was designed to prevent downtime at all costs. This was primarily through services deployed across data center clusters to ensure that even if a data center (or two!) went down, everything would continue to work.
AWS grew out of Amazon's "excess" infrastructure that was not used after holiday peaks had ended. AWS follows the same "no down time" design and most AWS products offer service agreements with strong estimates about how many "nines of availability" the service meets.
Is it just less work to take it offline?
If a website goes offline, what impact does it have?
For Amazon, offline equals lost profits. Thus staying online is an imperative.
It is easy to have near 100% uptime on AWS because AWS was designed to support Amazon's requirements. It does cost more because you would need to configure for multiple availability zones and elastic scaling.
Is the cost of that increased availability worth it to other web sites? Maybe or maybe not.