Bare metal on Kubernetes is a PITA though to set up. For extremely small scale stuff in private labs, okay, that takes half an hour, but as soon as you are on the Internet, maybe have a couple rented bare metal machines, it gets nasty. For ingresses, you'll usually need to set up MetalLB which requires acquisition of a range of IP addresses and it only is capable of running one server (the "speaker") as the one and only entrypoint for all traffic. Not to mention you cannot have roles such as "internet-exposed node" and "not internet-exposed node", since MetalLB wants to run on all nodes.

Also, a Kubernetes environment will need at least four separate network ranges - a network for the Pod IPs, a network for cluster IPs of services, one for the nodes themselves and if you want to expose stuff to the Internet you need a fifth one that holds the public-routed IPs. This is really funny if you are in a corporate environment that uses all three of the historic private ranges (10.0.0.0/8,172.16.0.0/12,192.168.0.0/16), good luck carving out ranges that do not result in routing conflicts.

Mesosphere DC/OS was more usable in that regard as it had pre-defined the roles of nodes, included the load balancer as part of the platform and had only two IP ranges (node-internal and whatever the public IPs of the public nodes were)... whereas it's clear that the only designed/supported way to run a major Kubernetes deployment is to use a fully-managed Kubernetes provider. Everything else is a world of undocumented, spurious-bug-filled stuff and incomplete documentation.

I think you are misunderstanding the previous comment. I read it as Kubernetes being so complicated (I enjoy it, but that's another discussion) to operate is making the regular bare metal operation more appealing. So people might choose the well understood bare metal over Kubernetes.