I would do cookie AND database -- otherwise how do you know who's who. A 'frequent purge' (four times a day from cron, deleting those > 24 hours old) of guest carts whilst RETAINING logged in user carts (which should be a thing) being pretty much the norm.
If you're selling users might want an account so they can access their cart from a different machine later. JUST cookies can't do that, localstorage sure as shine-ola can't do that.
I don't know what developers you're dealing with who put carts into localstorage, but that's the most jacktarded rubbish I've ever heard. PARTICULARLY since nothing client-side should EVER be trusted in that way. EVEN if you use AJAX to enhance the experience you should FIRST be writing your shopping cart so that it works WITHOUT CLIENT SIDE SCRIPTING! That way it is accessible to EVERYBODY.
Right now blocking scripting is as popular as ever -- in locked down workplaces, amongst the security minded, amongst those choked out under bandwidth caps -- hence plugins like scriptsafe, ghostery, noscript, etc, etc, all being popular.
This is even more true when your objective is to SELL THINGS. Build it to work with sessions, database, and normal HTML form submits first! THEN go through with scripting to enhance it with AJAX to avoid the page-loads for a smoother user experience for those with JS available/enabled.
Again, progressive enhancement, that way the page can gracefully degrade to be useful for everyone. If you do anything that means people can't shop without JavaScript, you're not doing your job, you're not doing the client any favors, and you're telling large swaths of the public to sod off!
... with both cookies-only and localstorage-only being client side scripting only solutions; aka utter and complete TRASH. Anyone telling you otherwise is either unqualified to their yap on the huffing topic, or is selling something.