In my experience (both myself and observing others) this is the cause of lots of side project (sometimes even startup) failure. Lots of people choose a tech stack that's far away from what they've worked with, so they never get past the "read the docs and try to get anything working" stage. For a real chance at completion it seems like the recipe for success is choosing a stack that's 1ish derivative away from a dev's competencies so they have a new and exciting thing to learn, but are able to continue progressing and adding value.
I am also a person that, prior to using Azure, was an absolute "Kubernetes is a big waste of my time and I'll just skip it" person. I wrote it off as predominantly "resume-driven". Now, having used Azure for about a year, I'm rewriting all my Azure infra to use AKS to better insulate me from the inevitable issues that come up when I GTFO of the Azure sphere as soon as our credits run dry. And, what I'm learning, is Kubernetes is a just-fine deployment/orchestration/management tool for containerized infrastructure that is _not_ a massively complex microservices infra. It's just a more streamlined approach to scaling and managing cloud-agnostic tooling/containers.
That said I agree with the innovation token concept. None of this junk makes you money, solve a problem first.