It's not about the shopping cart. It's about all the session data, especially for authentication. While you could use Dom storage for storing a session ID, you would have to send that through to the server with every request which you get for free with cookies.

Additionally, cookies can be marked as http only or even as secure, making it very hard to lose the token by virtue of a fire sheep like, or even just XSS attack.

For that reason, I personally would prefer a site using (session) cookies to one hacking it via DOM storage any day.

And finally, depending on the store you might want to persist the shopping cart between visits- likely across machines. Thus, the cart should be stored on the server and not in DOM storage.

It's probably necessary for click tracking. Macy's will pay either a CPC or a CPA for traffic coming into their website, and that includes traffic to their homepage.

keeping a session id in the URLs is way less secure as it is susceptible to XSS attacks, it can leak in referer headers, it can be accidentally shared by people copy & pasting the URL and by extension, the session ID might even end up in a search engine and depending on your bad luck, the bots might visit the page just often enough so the session doesn't expire on the server at which point an authenticated session is in the search engines.

Session cookies on the other hand can be marked as http-only, mitigating XSS in many browsers (there are some that still screw this up with XmlHttpRequest) and by not having the session id in the url, the id is much less likely to be shared with others, nor to appear in search engines.

Also, it keeps the URLs nice looking.

So why exactly would one want to disable session cookies?

Because of all of the above reasons, I'd much rather keep users with cookies disabled away from my application than to subject them to the ugly URL fallback which will impact their security much, much more than the perceived privacy loss of session cookies (which go away when you close the browser)