I could also further argue that there is no session, there is only a HTTP cookie representing state. And then argue that there are no cookies, just a piece of data sent by a website and stored by the browser, and so on..

The point is that the actions do not cease to exist simply because they are abstractions over a lower level of operation. Users don't need to know what sessions are and it detracts from the user experience, so its not a good idea to expose them to the details of that level of abstraction.

I don't believe a user is by default ignorant and I don't treat them as such it also doesn't detract from user experience as now we have session/{create,new,destroy] instead of what this very question presents.

I see no reason to assume that a user understands what HTTP sessions are on a site where the userbase is non-technical like gmail or Facebook or the vast majority of sites online. Mentioning sessions to them will detract from their experience. Furthermore, I don't think a technical user would be offended by use of a non technical term like login/signin if there's no need for a technical one.

Finally, I don't see any clear distinction between session/create and session/new. I'm confused about which one corresponds to creating an account vs logging in. I'd say confusing terminology like that is far worse for user experience than any of the log/sign options.

So can we take it that you are plumping for "authorize session" / "deauthorize session"?

session/new, session/create, session/destroy

Even logging in is orthogonal to session.

How about "authenticate"?