MicroK8s’s initial selling point is the developer-centric workflow, but it also supports a clustered deployment. I don’t believe that this has been charmed up. As you mentioned earlier, Charmed Kubernetes sits in this position.
Writing a Juju charm might not offer a lot of benefit for you right now. If you’re looking to reduce cognitive load, then learning a new tool complicates that objective.
To answer a broader question - why bother learning charms/Juju - Juju aims at a more difficult problem than the day-1 provisioning/set up step.
It takes care of a lot operational problems that are fairly brittle (hard coded CIDR blocks, hostnames, etc) with other tools. For example, your deployment can auto-configure itself depending the current situation. It greatly reduces the need for a service-discovery tool in the middle of your architecture. Each unit of inter-related applications have the ability to exchange information.
Learning Juju involves setting your expectations of DevOps tooling much higher than you’re used to. But that mental shift is quite a barrier to many people. We’ve used it to good effect here at Canonical. Every .deb and .snap delivered to you all around the world is served from a computer managed by Juju. We also manage infrastructure for banks and telcos. Without Juju, our service would be more expensive and less reliable.
That said - if you are starting from scratch, you may wish to park Juju as an option and come back to it when you’re off the ground with your current project. I have a suspicion that you’ll find the learning process frustrating, because it’s a little bit more complicated than it should be (we’re working on fixing that!).