Just a complement to @Anders's answer.
Cookies are one way to have stateful sessions in HTTP which by itself is a non connected stateless protocol. Sessions are necessary for web applications, and any in line business.
Cookies used to be frowned upon as was javascript in the early times, because first is a way to collect usage statistics and has privacy concerns, while the other allows the server to control the browser, which has security concerns. Nowadays, many sites are simply not useable with cookies or javascript disabled, and disabling them in a browser is not always a trivial task. So my opinion is that is fine to provide a service requiring cookies. Just display a warning page saying that your service requires cookies if you cannot establish a session.
URL rewriting is (was?) an alternative to cookies to provide sessions in HTTP. In that mode, you consistently add a parameter consisting of a key and the session identifier. All session data should be carried server side in that mode. That way there is no additional risk of data leakage because only the identifier is exchanged in the URL. The downside is that it is not bookmark friendly: the URL does contain the session id, so if you bookmark the URL of a page including it, you will get an invalid session error when you try to use it later. And it is much harder to use than a cookie to pass information between sites of same domain. For that reason cookies is now the standard way to have a stateful HTTP site or application.
People that do not like cookies will also argue that as there is no persistent equivalent in URL rewriting, and that persistent cookies are highly used to collect data on client behaviour, major Web companies (Google, Facebook, Amazon, etc.) willingly only allowed cookies to browse their sites, and that because of that URL rewriting has been more or less abandoned. Be it true or false, it is just now meaningless because the fact is that cookies are required by most sited and allowed by most users.