Conversations about hosting usually assume every site needs a database, a content management system, and some server-side code running on every visit. For a real slice of projects, that assumption no longer holds, and understanding why can simplify both hosting and maintenance quite a bit.
What a static site is, in plain terms
A static site is a set of already-generated HTML, CSS and JavaScript files, ready to be delivered as-is to each visitor, with no code for the server to run and no database to query at the moment of the visit. It is the oldest way of building websites, and for years it was associated with simple pages that rarely changed.
What changed is that tools now exist that generate those static files from content written in a more comfortable format, with templates and organisation, and regenerate them automatically whenever something changes. The result is still a static site from the server's point of view, but the process of building it is as comfortable as working with a traditional content management system.
What Jamstack is
Jamstack is the name given to this modern approach: sites generated ahead of time as static files, which for the dynamic part (a form, a search box, a shopping cart) rely on specialised external services instead of a server of their own running code on every visit. The site itself stays light and fast; anything dynamic, if needed, is handled by specific pieces bolted on.
The real advantages
Speed. With no code to run and no database to query on every visit, delivery is practically instant. It is the difference between serving a file that already exists and building the page from scratch every time.
Security. A large share of a dynamic site's vulnerabilities come from flaws in server-side code or in the database. A static site has neither exposed to the public, which removes an entire category of attacks at the root.
Less ongoing maintenance. There is no system core to update, no plugins with vulnerabilities to patch every week. The site, once generated, simply exists until it is regenerated with new content.
Lower hosting demands. Since it needs no database and no server-side processing, the hosting required is minimal: file storage and little else. This also means it handles large traffic spikes far more easily than an equivalent dynamic site.
The limitations worth accepting
It is not free. What is gained in speed and security is paid for elsewhere.
Editing content is not as simple as a traditional panel. Depending on the tool chosen, adding or changing a page can require a more technical workflow than logging into a panel and typing directly, though options exist designed to let non-technical people edit content without hassle.
Dynamic features need extra pieces. A contact form, an internal search box, comments on an article: none of that exists out of the box on a purely static site. A specialised external service has to be connected for each function, which adds pieces to coordinate instead of having everything built into one system.
It is not the natural choice for sites that change constantly with many different people involved. A single-author blog publishing every so often fits well. A site with dozens of people writing and editing content daily, with approval workflows, fits better with a traditional content management system built for that.
What kind of project it suits
It fits especially well for marketing sites with content that changes infrequently, portfolios, technical documentation, one-off campaign landing pages, and personal or small-team blogs where load speed is a clear priority.
It is not the best option for shops with large catalogues and complex checkout, communities with registered users interacting constantly, or any site where content changes continuously through many non-technical people.
What this means for hosting
For a purely static site, almost any hosting, including the most basic, is more than enough: there is no database to administer and no demanding server-side processing. The hosting decision stops revolving around processing resources and depends more on other factors: overall delivery speed, an included security certificate, and support if you need help with the initial setup.
It is worth clarifying that this is not a trend replacing WordPress or other content management systems: it is one more tool, useful for the right kind of project. Most sites that need frequent updates from non-technical people will remain better served by a traditional system.
A middle ground also exists
You do not have to pick one extreme or the other. Many traditional content management systems, WordPress included, now offer some way to generate a static version of the site from content managed the usual way: you edit in the familiar panel, and behind the scenes a set of static files gets generated, which is what actually gets served to visitors.
It is a way to keep the editing comfort of a traditional system while gaining much of the speed and security of a static site, without migrating the workflow of whoever writes the content. It is worth considering before ruling out a content management system on speed grounds alone.
Ask your host, or check the panel yourself, whether this kind of setup is supported before assuming you have to choose one extreme or the other for an existing site.