The HTTP protocol is stateless. Sessions are a way to preserve client state across HTTP requests. You may choose to do that with a platform's built-in session handling or do it yourself with query string parameters. Either way some concept of a session is necessary for many tasks.
Your colleague probably dislikes a specific implementation, or hasn't been using sessions for their intended purposes. If you need to retain information about a specific client connection across HTTP requests, you need some form of session persistence.
The following issues are implementation specific:
Untyped nature of session variables
Global scope nature of session variables
Load balancing servers losing sessions
Application pools/servers restarting
For example, I most often work in PHP and store my session information in a relational database. So my session variables are typed. Load balancing and server restarts don't cause any session issues.
This one is more interesting:
Session time-outs causing loss of state
Sessions are most often preserved via cookies. These can be deleted by the client at any time. But they can also be preserved via a query string parameter and therefore never time out on the client. The server timeout is up to you. So even this issue is implementation specific.
Let's not throw out the entire concept of sessions just because we don't like a particular implementation. Any good web application framework will facilitate using sessions properly to preserve user logins or retain anything else specific to the user's current visit. A user's database record can (and should) be used to store things specific to them when logged in. Anonymous visitors, however, may have temporary information also worth preserving in their session, such as a short list of recent pages visited or the preference to hide a notice they've already seen. Generally only smaller temporary information is appropriate for session storage.