Principle 1 on the Jekyll philosophy is 'no magic', and that's why I love it. It tends to behave as expected, and what it provides is simple enough that I maintain a feeling of full control over the output. I've wrote some little bits of JS to add minor client-side enhancements, and the Jekyll plugin system is easy to dive into if you want to add some site-render features. Great tool.
Kudos to the author for putting something up for discussion. Replace the word 'The' with 'My' in the title and it's a nice exploration of where React tooling for static sites is at.
Keep publishing and sharing mate, you're good at telling a story and have more good content ahead of you.
Plugins are optional. If you used Webpack directly to manage your static files you could just tell Jekyll to load them from whatever directory Webpack outputs them to and then you can build your SPA to render blog posts however you see fit.
If you're using React you would want to use a native Webpack config right? This way it works anywhere, and isn't tied into any specific static site generator.
Even with ~300 posts and ~100 drafts it only takes 2 seconds to see auto-reloaded updates when I'm actively writing. That's within WSL 1 too (room for speed improvements are there with WSL 2).
It also has nice plugins to process SCSS and bundle your CSS / JS, along with md5 tagging all static files for cache busting without having to use Webpack or do anything complicated. You just reference them using a specific plugin's template tag. But at the same time you can choose to use Webpack if you'd like.
I'm not sure why the author mentioned Jekyll is too restrictive. You can write plugins to do some pretty custom things. Like, I wrote a few lines of Ruby to parse out time stamps from a list to make them clickable links so that I can jump to that position in a custom audio player, very similar to how clickable time stamps work on Youtube. You can pretty much do anything.