Who this is for. Whoever reads the brief before the kickoff. After this page you can tell a requirement that rules out server-side rendering from a preference that does not.
Signal 1: the interface is an application
The user stays in one screen for a long time and its state changes continuously: dragging items between lists, building something step by step with a live total, working offline and syncing later. Each change would be a page load in a server-rendered site, and the state would have to survive every one of them. Phrases in a brief that point here: works offline, drag and drop, real-time, no page reloads anywhere.
Check the scope before concluding. If the application is one part of the site, a configurator or an account dashboard, it can be an island in a server-rendered site, and the rest keeps the platform's routing, cache and previews.
Signal 2: the front end must be shared with a native app
The same screens must run inside an iOS or Android app that cannot render the site's HTML, and the team intends to write them once. Then the front end is an application of its own and reads the platform through the API. Phrases that point here: same experience in the app, one codebase for web and mobile.
A native app that only needs the same content does not count. It reads the API like any other client while the website stays server-rendered.
Everything else is usually a preference
Wanting a particular JavaScript framework, wanting the site to feel fast, or wanting a front-end team to own the site are real wishes, and each has an answer that keeps the server-rendered shape: islands of that framework, the page cache and fragments, and a theme repository the front-end team owns. They are worth hearing and rarely worth the list in What a headless build gives up.