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.
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.