Web clients (browsers) communicate with web servers using a protocol called HTTP. HTTP was deliberately designed to be a stateless protocol., that is each request and response stands on its own, the server doesn't retain any record of completed responses, and doesn't link together the series of requests from a single user. Why was HTTP designed to be stateless? Primarily because it makes HTTP servers much easier to design and code, and makes them much less demanding of memory. HTTP was designed primarily as an information retreival system and there was almost no notion of using it as an application programming platform. Even today most HTTP traffic consists of simple requests and responses with no need for state.
Around 1992-93 folks started writing web applications (as opposed to simple web pages). They immediately ran into a need to store the state of the application over multiple pages. They began writing extensions to the web server that could store and manage state using cookies and url rewriting to associate HTTP requests with particular sessions. As awkward as this is, it has the virtue of flexibility. If folks designing HTTP had tried to specify a general purpose state mechanism, they probably would have gotten it wrong, and we'd be stuck with it as part of the standard. ASP, PHP, JSP, and the other server side scripting languages are the offspring of those old web server extensions.
Many other network applications use the notion of a session (SSH and SMTP for example), but the contents of the session are hardwired to the details of that application.