The primary security reason to avoid cookies would be to prevent CSRF attacks, which is a valid goal. Cookies were not well-thought-out from a security standpoint. On the other hand, there are well-established approaches to avoiding CSRF, so it's not a hugely valuable technique.
From a privacy standpoint, cookies (especially third-party cookies) are dangerous. For this reason, some users and/or browsers block them, which can provide developers with a functional reason to use something else.
However, even for a single-page application (SPA), you probably want to persist your session token. The standard way to do this from JS is to use local storage (either persistent or session storage), which is basically a way to store JS variables for a particular site across user visits, or at least page loads within a given session. All modern browsers support local storage.
The main security downside of local storage (or any other way of doing programmatic session management on the client, instead of relying on the automatic behavior of cookies), is that an attacker that gets XSS (Cross-Site Scripting) within your web app can steal the token and hijack the session to impersonate the victim, even after the victim closes the browser (by contrast, the typical session cookie is flagged as httponly, which prevents JS from reading it and restricts session hijacking to only as long as the victim leaves the web app open).
document.cookie)