For your average developer who just wants to get something running on a port, Kubernetes introduces two barriers: containerization and Kubernetes itself. These are non-trivial things to learn, especially if you don't have an ops background, and both of them add substantial debugging overhead. And again for that developer, they provide very, very small gains.
I think the calculus changes if that developer starts to run multiple services on multiple servers, wants to keep doing that for years, and needs high uptime. I have a bunch of personal services I run in VMs with Chef, and I'm excited to convert that over to Kubernetes, as it will make future OS upgrades and other maintenance easier. But my old setup ran for something like 6 years and it was just fine. For hobbyists whose hobbies don't include playing with cluster-scale ops tooling, I think it's perfectly fine to ignore Kubernetes. It's the new hotness, but it doesn't provide much value for them yet. They can wait a few years; by then the tooling will surely have improved for low-end installs.
From the application-developer side, I'd dispute this. I was told to use Docker + Kubernetes for a relatively small work project recently, and I was able to go from "very little knowledge of either piece of tech" to "I can design, build, and deploy my app without assistance" in about 1 week of actual study time, spread out over the course of the project. And although I have several years' experience, I'm not some super-developer or anything.
What surprised me most is how well-documented (for the most part) everything is. The Kubernetes and Docker sites have a ton of great information, and the CLIs are rich and provide a consistent interface for all the details about your environment. (To tell the truth, that alone makes the time investment worth it.)
After this, there's no way in hell I'm going back to Heroku or similar and trying to piece together their crappy, one-quarter-documented "buildpack" system. I'd take a Kubernetes-and-Docker-first PaaS at a reasonable markup any day of the week.
I don't know if I'm totally convinced by that argument alone, but it would be nice if every critical response didn't seem to assume that every hobbyist is born understanding systemd, ansible, packer, qemu, etc.
Right, but again I think the point being made is that, if those are skills you do want to learn, or plan on using later down the road, it's worth knowing that you can use K8s even at a small scale.
Obviously, in most cases it could be premature optimization, but for some people (including you), it can be fun to learn.