Static sites served from the filesystem directly through any reasonable webserver are always going to be quick. 100k hits per month is nothing and a hackernews spike should not even be noticed unless you are serving up video or something large.
My site sits on a $5 DO droplet and I have never even come close to hitting any kind of limit despite the occasional traffic spike.
Dynamic content management systems are a convenience for the developer/maintainer of the site but push additional requirements onto the hosting CPU (and the client for javascript heavy sites). The cost of these requirements is often not clear but usually much larger than you might expect.
> Dynamic content management systems are a convenience for the developer/maintainer
It isn't harder to call a script that regenerates the static files.
It is just that dynamic content management systems are more common.
It’s harder to scale it properly over time, because every new post takes longer to regenerate aggregated pages. Obviously this can be somewhat lightened with some hard choices (e.g. only have aggregated pages by fixed period), but it is a tradeoff that dynamic sites typically don’t have to worry about.
Anybody who was around during the first blogwave in the early 2000s knows the score: after a while, with static generators you end up waiting a lot after hitting “publish”. And god help you when you change the template over the whole site.
Of course, dynamic systems have their own tradeoffs, but they tend to scale better by volume content. You can then slap a simple cache in front and be done with it until views get in the hundred millions.
If there was a need for it, static site generators could be scaled to tens or hundreds of thousands of pages and still finish in a few seconds. Caching partial results is always an option.
There are generators that are decently performant, like Hugo (Go) [1] or Zola (Rust) [2].