All three can produce a good website. They differ in what happens afterwards, who can change it, what it costs to keep, and whether you can take it with you.
The question that decides it
Who will update this site, and how often?
Everything else follows. A site that changes weekly and is edited by someone non-technical has different requirements from one that changes twice a year and is maintained by a developer.
A hosted site builder
Fastest to launch. No hosting to manage, no software to update, no security to think about, and templates that produce a competent result without design skills.
The cost is that you are renting the whole arrangement. The site is generally not portable. There is no export that produces a working site elsewhere. Leaving means rebuilding.
You are also limited to what the platform offers. When a requirement falls outside it, the answer is usually that it cannot be done.
Right for a small site that needs to exist, where nobody wants to think about maintenance, and where being tied to the platform is an acceptable trade. Moving from a website builder to your own hosting walks through the exit when it stops being acceptable.
A CMS on your own hosting
WordPress and similar. The middle option and the most common for good reasons.
Non-technical people can update content. There is an extension for most requirements. It runs on ordinary hosting, so it moves between hosts freely, and the content is in a database you own.
The cost is maintenance, and it is real. The core software, the theme and every plugin need updating, and each of them is a potential security exposure. A site left unmaintained for a year is not merely out of date. It is a probable compromise.
That work is small if it is done regularly and large if it is not, which is exactly the pattern that leads to it being neglected. Keeping WordPress updated sets out making it routine.
A static site
Pages generated in advance and served as files. No database, no application, nothing executing.
Consequences: it is extremely fast, it handles traffic spikes without effort, there is essentially nothing to attack, and hosting it costs very little. Backups are a copy of a folder.
The cost is that every content change is a technical step. Editing means changing files and rebuilding, unless you add a separate editing system, at which point you have reintroduced part of the complexity you avoided.
Right for documentation, a portfolio, a marketing site maintained by developers, anything where content changes rarely or the people changing it are technical.
What each is hard to leave
This is worth weighing at the start, because it is invisible until it matters.
A builder is hardest to leave, usually a rebuild.
A CMS is easiest to move between hosts and moderately hard to leave for a different system, since the content exports but the presentation does not.
A static site is trivial to move anywhere, because it is files.
What does not decide it
Which one is capable of building your site. All three are, for the overwhelming majority of sites.
Also not performance in isolation: a well-cached CMS is fast enough that visitors will not tell it from a static site. Understanding caching layers explains getting there.
Selling things
A store is a different decision, because it involves payment handling, tax, stock and order records.
Builders offer commerce with the same trade as before: quick, restricted, hard to leave. A CMS with a commerce extension gives you control and adds maintenance. A static site cannot do it alone and needs a hosted checkout alongside it.
Comparing hosting tiers walks through what any of them will need to run on, and preparing a launch checklist explains the work that is the same whichever you choose.
Work out what leaving would actually involve
The choice is easier when it is framed as which future migration you are prepared to do, since every option eventually needs one.
From a hosted builder, the content usually comes out as text and the design does not. The addresses change, which means redirects you may not be able to configure. That is the most expensive exit of the three.
From a content system on your own hosting, everything is in a database and a directory, both of which you can copy. The exit is work rather than reconstruction.
From a static site, the files are the site. There is effectively nothing to leave, which is why it is the least constrained option and also the one that does the least for you.
Count the ongoing work honestly
The three options differ mainly in who does the maintenance, and that cost is continuous rather than one off.
wp core check-update 2>/dev/null wp plugin list --update=available --field=name 2>/dev/null | wc -l
A system on your own hosting needs updates applied, tested and occasionally rolled back. That is a few hours a month done properly, and skipping it is how sites are compromised.
A hosted builder does that work for you and charges for it. A static site has almost none, since there is no application to update, and the trade is that adding a feature means somebody who can write code.
Choose the option whose ongoing cost you are actually willing to pay, not the one whose starting cost looks best.
Who edits it decides more than the technology
The question that predicts success is who will change the site in six months, and how comfortable they are.
A site nobody can update becomes stale regardless of how well it was built. That is the common outcome for a static site handed to somebody who does not write code, and it is a worse result than a slower site the owner can maintain.
The reverse also happens. A flexible system given to somebody who does not want to learn it produces a site that is edited once and then abandoned to whoever built it.
Match the tool to the person rather than to the requirements document. Working with a web developer covers the handover either way.