According to the PHP manual and the Programming PHP O’Reilly book, the only datum embedded in a PHP session cookie is the PHP session ID. As a session can be started before a user has actually been authenticated, the presence of the session cookie in itself is not an indication that a user has logged in.
I'm not saying the server has to always and forever treat the session cookie as proof you are a particular user, whenever the cookie is presented, as that is obviously not the case. I am saying that, if someone gets your logged-in session cookie, that can be as good as having your credentials for any system that is *ever* in a state where presenting the cookie will result in the server treating that request as coming from an authenticated user - for as long as that session cookie is valid.
It doesn't matter that there is a period where the server will have a session setup without authentication (although hijacking that cookie could well result in stealing that unauthenticated session) if what is being done is a hijack of an actually authenticated session.
That said, I can agree with “effectively” in your statement if a session is started after log-in, user-identifiable data is encapsulated in the PHP $_SESSION[] global array associated with that session and each page visited by the user checks $_SESSION[] for the presence of that user-identifiable data. That being the case, deleting the session cookie from the browser would be an effective log-out (but not a clean one), since the server side would no longer have a way to relate the user’s browser to the session that was started on his/her behalf.
It doesn't have to be each page - there only needs to be one. It also isn't PHP specific: plenty of CTF have solutions that require session hijacking against servers using various implementation languages; plenty of CVE have been issued for session hijacking in real products (web application languages like php, server software, even 'that network device over there in the rack with that web configuration ui').
There are, of course, various mitigations. Invalidate a session if the user-agent header changes - which is a fine preventative measure up until your attacker is stealing the cookie by capturing traffic; as that traffic will have the user-agent header in it. Just guessing the header can work too, if enough is known about the target to reasonably narrow down the range of possible values, and the attacker thinks it's worth it. If the server only allows https then the 'capture traffic' route is closed, of course.
Then there's the item that started this subthread: If the server invalidates the session as soon as it notices an IP address change, now the attacker is in a spot where even with the session cookie, they have to either be attacking from the client with that IP address, or in circumstances where they can arrange to spoof the IP address (which is certainly a higher bar).
