I work for a CMS company (but not one of the ones OP mentioned), and many of our customers use SSGs. FWIW, I think there's some good findings in the OP and the follow-up comment.

That said, IMO, they're not the best solution for:

> I'm a novice with no expertise in website building or design.

<user hat on>

SSGs don't prioritize ease of use, necessarily, but simplicity and cost of hosting. If your only goal is to get a very simple website up and running, using a CMS + SSG + configuring hosting is kinda overkill, IMO. You might save $10/mo but end up spending hours longer to get it up and running.

Aside from Squarespace, there's also Wix, Weebly, Wordpress.com, and a bunch of other WYSIWYG page builders, many with free plans. Those are probably more appropriate for generic small-biz websites, not only because they are easier to use, but because it's a single-source solution. If something's wrong, if the site goes down or you don't know how to do something, there is one company to reach out for support, and it's their sole responsibility to make sure your website still runs.

If you use self-host a CMS and host it on a VM, use a separate SSG to publish your files to be hosted on yet another host... that's like 4-6 sources of potential failures, and nobody to support you through the whole journey. It can cause a lot of frustration later on if you run into bugs you can't easily solve on your own.

A large part of my job is supporting customers in similar circumstances, and the lines between "I coded something wrong" and "there's a bug in the CMS" and "there's a bug with the SSG software" and "there's a bug in my webhost config" and "there's a network/caching issue with the webhost themselves" can be very blurry. If you don't have at least some basic networking and frontend experience, this sort of setup adds quite a bit of fragility and complexity over your typical $10/mo vendor-supported small-biz site. That's not a good value for most people. Even tiny nonprofits can afford $10-$20/mo for "normal" web hosting that they don't have to babysit constantly.

</user hat>

-----------

<dev hat on>

Where SSGs and Jamstacks ARE valuable are for small to medium teams who want a clearer separation between content, data storage, and presentation -- usually because different individuals work on different parts, so you don't get marketers accidentally composing invalid markup or breaking JS, and you don't get dev code pushes interfering with the editorial process.

Content: Whether there's a WYSIWYG GUI editor or Markdown files, the point of this part is to make it so that anyone can edit articles, add images, etc. without extensive training.

Data storage: This can be flat files, a real database, NoSQL, whatever. It can be self-hosted or vendor-hosted.

Presentation: You can use a built-in template, extend one, or fetch your content via API and write a bespoke frontend from scratch.

Overall, the basic idea is simply a separation of concerns. Different software/teams/individuals can focus on their areas of expertise without accidentally stepping on someone else's toes.

That's hard to do in a "traditional" full-stack CMS setup like Wordpress or Drupal, which has hooks into all three parts, and usually deploys them together. That's why companies like Pantheon, WPEngine, and Acquia had to create their own virtualized hosting and deployment pipelines (like Pantheon's: https://docs.pantheon.io/pantheon-workflow), which give you a cleaner separation of concerns by imposing an out-of-band system that lives outside the software itself.

The headless CMSes (or even Wordpress & Drupal, configured appropriately, like using Wordpress Advanced Custom Forms or the Drupal REST API) + a SSG, on the other hand, do this natively.

The content editors get a nice interface they can use to add posts and media. They don't have to worry about breaking any code by accident, or configuring schema and plugins, or invalid compositions of content. It's a "walled garden" (lined notebook? not sure the best analogy here, lol) of the good kind: it lets them do their jobs without extraneous concerns/risks.

The data storage is abstracted away, and in the case of vendor-supported solutions, don't require any maintenance or backend staff to support. Even if you self-host, usually this layer usually requires minimal time, maybe just the occasional software update to the latest version (assuming nothing breaks).

The devs can now focus on frontend code, whether it's a webpage or an app or whatever the next-gen presentation interface is. They can rewrite the entire frontend time and time again without interfering with the editors. If they want to do it in Next.js now and rewrite the whole thing in HTMX tomorrow, they have that option, and editors never have to care or stop working. It's all just fetched via API.

</dev hat>