But it only has one page dedicated to it consisting of three paragraphs
Sessions will always be hackable somehow.
Sessions work by sending the session id with every http request. Either in the request headers by posting a cookie or via the url. Anyone who is monitoring your TCP traffic can get your session identifier and other information (such as expiry) and use it.
You could implement an IP check.. again those can be spoofed.
You could use SSL.. not much good if the users system is infected with a trojan (plus SSL is crackable).
You can use random keys in the url but the user only needs to open a link in another tab.. so you implement rolling keys.. that becomes even more complex and to accomodate it you have to have several keys available and thus the attacker could borrow one of those..
The problem with sessions is that they depend entirely on the users browser to work. With that being the case, you will never come up with a 100% solid way of protecting them and that is why php.net have such a short article about it on the page you link to because in reality, you cannot completely safeguard against hijacking.
As for why someone would want to implement their own sessions system, quite simple really, phps native session handler has garbage collection and can be a pain when sessions timeout after 24 minutes (this can be a pain to change). Implementing session storage in a database means you can ignore the garbage collector and keep those sessions available until a time when you wish to delete them. Thats the first reason I can think of..