We build on both, so we have no particular stake in the answer. That turns out to be the useful position, because the platform is the last decision, not the first.
1. How many places does this content need to reach?
If the answer is one website, and it will still be one website in three years, a well-run WordPress build is very hard to beat. Headless separates content from presentation so the same content can feed a site, an app and a screen in a shop. If you only have the site, you are paying for flexibility you will not use.
The moment the answer is two or more, the economics change. Structured content modelled once replaces the copy-and-paste sprawl that quietly eats editorial teams.
2. Who edits it, and how comfortable are they?
WordPress gives editors preview, scheduling and layout control on day one. Headless setups can match that, but it takes deliberate work, and if that work is skipped your editors end up filling in forms with no idea what the page will look like.
Teams don’t outgrow WordPress. They outgrow publishing to a single website.
3. Can you own a separate front end?
Headless means a front-end codebase that somebody has to build, host and maintain. If you have developers or a partner running it long term, fine. If not, you have swapped a maintenance problem you understood for one you don’t.
4. Who is running this in three years?
Licence costs, hosting model, how easily you can hire the skills, and how hard it is to leave. This question kills more architectures than any technical requirement.
The short version
One team, one website, no in-house developers: WordPress, built properly. Several channels, structured content, someone to own a front end: headless earns its keep. If two platforms both fit, the tiebreaker is what each costs to run over three years, not which demo looked better.