I use the one situated in Seattle, Amazon HQ. It's just like self-checkout at a grocery store with fewer steps. The entrance/payment mechanism is Amazon One (a palm scan associated with a payment wallet). At Whole Foods, it's used as an optional payment option at checkout.
It's convenient; I only ever remember one problem where it thought I had purchased an item that I picked up and decided on something else. I disputed it online and it was resolved in a day.
Oh man this is what consumers would love to do, have to constantly adjudicate false positives online which they'd have to track to make sure didn't happen. What nonsense.
Probably not for the cartoons, but we're hard-wired for emotional empathy that depictions of it are eye catching enough to get attention (and then motivate others to action once they understand the purpose of those stickers).
The Drupal community made a pivotable decision that ensured it would never "win" a CMS battle with WP.
Wordpress has always been a more product-focused blog/site-builder that works out of the box and simplifies code concepts for an average user who doesn't need to know much PHP to get everything they want to be done. It has always focused on open-source PHP CMS as a product.
Drupal has always been an engineer-first CMS; D8 doubled down on that: focus on long-term maintainability with OOP/Symphony/Composer/etc. That decision caused the casual site-builder who knew little PHP code to say "no thanks". It has always focused on open-source PHP CMS as a framework.
Backdrop happened for those who wanted a good off-ramp for those who were happy to keep the current Drupalisms of D7 and didn't need more PHP-web-dev tools. Unsurprisingly, it became more WP-like as it tilted more toward PHP CMS as a product.
The current community of the Drupal world has kept focusing on improving the UX of the site builder/maintainer role with its current initiatives (auto-updates, project browser) to self-correct.
Ultimately, Drupal focused more on its core strength. That's not a bad thing, that's just product differentiation. It turns out the average website doesn't need to maintain a lot of custom CMS code/workflow/logic they just need to track a handful of blobs of text/image content.
I think YRMV depending on what you're trying to do, but I think the DX & web console experience is much more pleasant on GCP.
On GCP, their services are cleanly organized and have distinct icons that tell me what it does with minimal reading. On AWS, often I'm left scratching my head (see https://awsiconquiz.com/)
The web console design on AWS is catching up (for a long time the UI just looked like an offshoot of the e-commerce site design and wasn't very clean) to GCP, but occasionally you still find elements of the old AWS console design.
Often, it seems like AWS has more leaky abstractions that require you to be more aware of all the other connecting components of their infra services.
For example, trying running managed Airflow on AWS/GCP. Both services require some VPC & storage infra setup to get your Airflow container services running. On GCP, you can spin up Cloud Composer without specifying your VPC or storage bucket details and they'll default them for you.
AWS however, you'll need to have your VPC/S3 already setup ahead and if you've not configured your private/public subnets or S3 IAM policy, you can put your Airflow environment into a non-workable state.
Overall, I think GCP has some advantages of not being saddled with legacy baggage that AWS has with making sure their services are interoperable.
I agree - Kubernetes on AWS was a bit of a shock after using it on GCP (yay) and Azure (meh). I think it makes sense if you've used AWS for a while, and know the security groups etc dance, but it was a bit jarring.
It's convenient; I only ever remember one problem where it thought I had purchased an item that I picked up and decided on something else. I disputed it online and it was resolved in a day.