It's because these systems were created with the focus being how cool it'd be to make a static site generator, versus the focus being solving a real problem. W

It's because these systems were created with the focus being how cool it'd be to make a static site generator, versus the focus being solving a real problem. We do this. I do this. We like to decide "how cool it'd be..." and do something. There's nothing bad in that, as long as we don't start coming up with invented reasons for its reasons to be. When asked to quickly name a tool, most people say "hammer". When asked to quickly name a site application, most people think "blog". The focus on blogs inadvertently tells you that these authors were scratching their own itch of making the generator itself, and focused on the first application they could think of, and not responding to real needs. I remember when the coolest thing was for everyone to make their own web framework, everyone focused on making frameworks where blogs were easy to set up and demo. Notice a pattern? In the end though, all sites need a machine to be put on, a server to serve them, and the arbitrary goal of pre-generating basic things like header and footer includes externally has little real value to offer when it comes to business needs ("business" used in a wide sense, as in people's real reason to have a site in the first place). Any non-static site can maintain a static cache when performance is needed, and any non-static site can be as simple (and therefore as secure, by function of its complexity alone) as you need it. Maybe your non-static site "engine" can just do basic includes and support a contact form, and nothing else. It's easy to secure this, and you draw the line. But there's no need to ever cross that specific line where your site is 100% static. You have nothing to gain from it.