I liked to put the line between whether you're required to sign in to use it or not. If none of the data was necessarily publicly accessible anyway, that's more of a spa suited interface
Well, it would be one of many. Considering building an SPA for a paywalled content site would be a little surprising to me in the first place, but it would make a lot of sense to me for any of the behind-the-scenes or account management facilities you'd only ever see once you've logged in. I wouldn't expect the content view to either be sufficiently interactive on its own, or sufficiently interactive when coupled with other aspects of the UI, to require the complexity of an SPA at all.
The full set would be something like who the target market is, whether it's a completely internal or completely standalone thing that just happens to be built with web tech, whether it's intended to be offline-capable and whether there's a lot of state involved in the interactive capabilities of most views, should there be the capability to do any kind of concurrent UI things like picture-in-picture video while someone navigates the rest of the screens and changes data frequently, and then the importance/complexity of maintaining a high-level of accessibility.
What I was describing could maybe be conceptualized as multiple applications that serve one larger site. You have the public facing staticly rendered site, built in whichever way, but that ultimately has accessible rendered content on page load and as fast as possible. Then you also have interfaces to the data that is rendered there, which might be completely separate codebases for different purposes.
These could also take place in things like a reporting portal inside a company, where stakeholders need to regularly see static or filterable reports of pre-rendered data, and then you have other internally available apps that different departments can use to manipulate that data in ways that they can easily receive immediate feedback on whether or not it's valid or how it looks etc..
