Because caddy/nginx/apache (any web server really) can serve that content as well as any other? Better question is; why default to using more things before you actually need them?
Personally, software engineering for me is mostly about trying to avoid accidental complexity. People obsessing about "web scale" and "distributed architecture" before they even figured out if people actually want to use the platform/product/tool they've used tends to add a lot of complexity.
> Because caddy/nginx/apache (any web server really) can serve that content as well as any other?
That's not really true if you care about reliability. You need 2 nodes in case one goes down/gets rebooted/etc, and then you need a way to direct traffic away from bad nodes (via DNS or a load balancer or etc).
You'll end up building half of a crappy CDN to try to make that work, and it's way more complicated than chucking CloudFlare in front of static assets.
I would be with you if this was something complicated to cache where you're server-side templating responses and can't just globally cache things, but for static HTML/CSS/JS/images it's basically 0 configuration.
> That's not really true if you care about reliability
While reliability is always some concern, we are talking about a website containing docs for a nerdy tool used by a minuscule percentage of developers. No one will complain if it goes down for 1h daily.
With the uptime guarantees AWS, GCS, DO, etc. provide - it will probably 1h per 365 days accumulative (@ 99.99% uptime). 2 nodes for a simple static site is just overkill.
But, honestly, for this: just use github pages. It's OSS and GitHub is already used. They can use a separate repository to host the docs if repo size from assets are a concern (e.g. videos).
How is setting up a web server not using more things than you need when you could just drag and drop a folder using one of many different CDN providers? (Or of course set up integrations as you want)
Just because you're using a UI doesn't mean it isn't more complicated. I'm thinking "complexity" in terms of things intertwined, rather than "difficult for someone used to use GUIs".
Personally, software engineering for me is mostly about trying to avoid accidental complexity. People obsessing about "web scale" and "distributed architecture" before they even figured out if people actually want to use the platform/product/tool they've used tends to add a lot of complexity.