It may be overkill at first, but run a site for long enough, and the static generator starts to make a lot of sense.

I originally had static HTML, but that was well over 10 years ago at this point. Soon you want to wrap your pages with a template to get rid of boilerplate and keep your site consistent. Then you want auto-generated indexes, and maybe you want to check for broken links, add width/height to <img> tags, etc.

My personal website has hundreds of pages on it, not counting the auto-generated index pages. Automation is a necessity at this point. It is still written in HTML... I never adopted anything like Markdown, and I've abandoned any use of custom syntax like Hugo's or various templating systems, at least, outside the static site generator code itself.

The problem with straight HTML, as opposed to one of the markdown-to-HTML pipelines, is that if you want to change something, it's really difficult (bordering on impossible, depending on how consistent you've been).

I migrated my blog a year and change back from Blogger to self hosted Jekyll (a rather consistent theme on this post...), and having the content, the "scaffolding" (HTML templates and such), and the render pipeline being separate means that it's trivial to change things if I want to.

As a recent example, I realized a few months back that my blog didn't render at all with Javascript disabled. That's not OK to me (it was a quirk of how the template I bought did a "gradual fade in" once the content was loaded - looks good, requires JS, I do not care about that sort of thing). To eliminate JS requirements, I had to eliminate that fade, and I had to change image embedding for a lot of things such that it didn't use lazy load - there was some JS based lazy load that meant post thumbnails and such didn't load. All I had to do was change the templates, re-render, and re-upload the site (I rsync stuff up). That would be harder to change in HTML.

The same goes for images and such. I end up with several versions of each image used - if your browser supports picture sets, it will "pick the best" based on what the browser thinks is reasonable, in terms of size and formats. I currently render to a few different resolutions of jpg (or png) and webp from the original source images. If I want to change that, add a new resolution, or add a new format, I just update a config file, re-render, and I'm done. That sort of thing helps with keeping the site "modern," if you care about it.

For an absolutely basic "few pages" site, sure, you can do HTML. But for anything with regularly updated content (I have ~260 blog posts and nearly 6000 images), it's well worth having some helpers to separate content from layout/formatting/features/etc. Despite that, it's still very much a personal only site, I'm the only author, it (now) renders without JS, sets no cookies, etc.

FWIW you can use any SGML processor to separate-out boilerplate from content files using entities (text macros), and more advanced forms of HTML templating. Makes sense since HTML itself, originally conceived as an SGML vocabulary, lacks these authoring features since present in the larger SGML context/toolchain. You can also typecheck your documents and even format markdown into HTML using SGML's SHORTREF feature; checkout [1].

[1]: http://sgmjs.net (my site)

Hugo and others help with things like autogeneratings tags and sidebars, that sort of thing.