Sometimes you'll see people saying things like:
Using cookies to track state on a website, that is only used for that website, is fine. You don't need to ask for consent.—rrwo
Or:
You don't need a cookie banner to be allowed to create cookies. You only need them if you're using them for something like tracking.—y4mi
Something like, "as long as you design your site properly and don't abuse storage you don't need to ask your European visitors for permission." While I'm not working in this area anymore, am not a lawyer, and am not attempting to give you legal advice, if you read the regulation this interpretation is completely off.
Cookie banners are a response to the 2002 ePrivacy Directive (full text, guidance). While the ePrivacy Directive may be superseded soon by the (pretty similar) ePrivacy Regulation, it's still the current rule. It requires you to get consent from visitors before you store information on their computer (cookies, localStorage, etc) unless this behavior is "strictly necessary in order to provide an information society service explicitly requested by the subscriber or user" [1]. This isn't "in order to" or even "necessary in order to", it's "strictly necessary in order to". Which is quite firm!
This excludes, for example, using a cookie for basic single-site analytics (4.3), where you want to figure out where users are getting stuck on your site or to populate a "users who viewed this product ended up buying this other product" box. Even though this information helps you improve your site for future visitors, including potentially this one, it isn't 'strictly necessary' for serving this user right now.
If the user puts an item in their shopping cart you can set a cookie, because that's how you honor their request, but it's still quite restrictive (2.3):
a merchant could set the cookie either to persist past the end of the browser session or for a couple of hours in the future to take into account the fact that the user may accidentally close his browser and could have a reasonable expectation to recover the contents of his shopping basket when he returns to the merchant's website in the following minutes.
Maintaining a shopping cart across days isn't "strictly necessary" and so requires explicit consent. Despite it being a useful thing users may be expecting: if I put things in my cart, don't check out, and come back the next day, I'm going to be frustrated if the site has forgotten my selections!
Similarly, say you have a "language" dropdown or a "dark mode" checkbox". Unless you have explicitly marked the UI control with text like "uses cookies" (3.6) you can't persist this setting for future visits.
The overall effect of this is that most sites will not be ePrivacy-compliant unless they either (a) get cookie consent from users or (b) hire a lawyer to review each of the things they do in the context of ePrivacy, and make careful changes to keep everything within the tight bounds of "strictly necessary". It's not surprising we see so many cookie banners!
[1] Technically it's also allowed if it's "for the sole purpose of
carrying out the transmission in the electronic communications network
and provided that the information is not stored for any period longer
than is necessary for the transmission and for traffic management
purposes, and that during the period of storage the confidentiality
remains guaranteed". But the "strictly necessary" criterion covers
almost everything in practice.
I think #1 is definitely the case: if you have to put up a banner even to do normal things that few people object to, might as well also include profitable things that are less popular. On the other hand, there are also a bunch of things that are important for the proper functioning of websites in the long term but are pretty hard to convey clearly in a banner. This is things like, as a way to verify that changes haven't broken your site you typically want to roll them out gradually as an A/B test, which requires collecting enough metrics that you can tell whether and how A and B are performing differently. This is good for users in aggregate in that the site gets improvements faster and is less likely to have broken functionality, but is just kind of complicated.