When you'd build the page dynamically, you'd also write a static .html before serving the html to the visitor. From then on, the .html got served.
On a new build, you'd rm the .htmls.
Back at the time, it seemed to be "the simplest thing that could possibly work" for multiplying a server's traffic capacity by 10000.
Strange to say use rails for static, but the author argues how server less is a nightmare. Though, I also think the same, use nextjs just for the react frontend and a proper backend.
Just use hugo/whatever and host on s3. This shouldn't even be a debate, let alone they've already done 3 rewrites. Bunch of clowns.
If you're hosting a static site... life is easy. Throw your content in any s3 compatible storage and point a CDN at it. Done. It will cost literal pennies a year (The domain name will be by far the most expensive piece, and lots of places will give that to you for free if you don't care about being a subdomain).
That too complicated for you? Host it on a raspberry pi out of your bedroom. For the vast majority of traffic loads... that thing is going to be A-OK, even on a crappy consumer line (You'll probably be violating your TOS with your provider if it's a commercial site... but I've found they really don't seem to care unless you're causing them headaches, and a static site ain't gonna cause many headaches).
That too complicated for you? 10 lines of js with express will stand up a prefectly functional static site. Or you literally just install nginx and configure a single server block.
Static sites are fucking easy. It is ridiculously easy to serve static content these days. And borderline free (again - the domain name is going to DWARF the rest of your costs combined, even if you're only paying 5 bucks for the name).
How do you generate your static content? Who cares - do whatever feels best to you (I personally think rails is a bonkers solution, but if you want to use rake tasks to create your output... more power to ya?)
It really sounds like the author doesn't understand what a static site is, because JAMstack also isn't a static site solution (It has API right there in the name).
If you need to be consuming APIs with changing data... you aren't a static site (even if the html/js/css you serve happens to be static). In which case... rails is a fine choice, but if you're only serving the html/js/css and hitting 3rd party apis... I would still recommend an s3 bucket with a CDN.