This solution is sort of weird to me. To me, the allure of a static site or a static blog is to simplify the stack; To bring it back to the basics. Static HTML served by a good ole-fashion web server.
Adding the cognitive burden of "serverless" and/or lambda just to schedule seems to complicate something that isn't very complicated. Its almost like an invented problem.
That said, long live this static site generator movement.
I'm betting this movement will continue to grow which is why I'm bootstrapping https://www.remarkbox.com (comments-as-a-service)
I use jekyll NOT because it's simple (Actually it's 100 times more complex to use than a simple wordpress or medium) but because:
1. I can keep track changes with git
2. I can host them on Github pages for FREE
3. I own the content
4. More flexible
In fact I've been really annoyed with all the boilerplate code and extensions I need to deal with in order to have a "usable" workflow set up, I almost thought about moving back to free blog services like medium, tumblr, wordpress, etc. but the only reasons I can't are the ones I mentioned above.
But my point was it's not just about "simplifying the stack". You said "the allure of a static site or a static blog is to simplify the stack;", but the thing is, not everyone thinks that way.
A possible goal is to have the serving stack be as simple as possible.
After all, you can argue that the publishing-side stack is anyway very complex: it includes e.g. the Github UI, if one makes edits using the Github UI.
Adding the cognitive burden of "serverless" and/or lambda just to schedule seems to complicate something that isn't very complicated. Its almost like an invented problem.
That said, long live this static site generator movement.
I'm betting this movement will continue to grow which is why I'm bootstrapping https://www.remarkbox.com (comments-as-a-service)