For a $5 product it may not make sense to have this level of configuration, but for example I believe the FireBrick (a device you might buy to put a small company or district office online) is capable of being configured with your name rather than a generic product DNS name that could go away.
Also, just because a name is in DNS doesn't mean you must use the Internet to resolve the name. In a truly offline system you can just hard code that name resolution and it'll work fine. Nothing about HTTPS cares how resolution was actually done, only the BRs for the Certificate Authorities tell them they mustn't issue for names that aren't actually part of the public DNS hierarchy.
So, the device needn't be on the Internet.
The name must make sense in the Internet DNS hierarchy, but (with a typical commercial CA) needn't actually exist or (with Let's Encrypt, who insist on checking) needn't resolve to anything, let alone an actual machine on the Internet
Yes, you will need to move new certs to a device if you want it to remain publicly trusted as time passes. If that's an unacceptable burden (maybe your device is under the North Pole ice) then you probably didn't want the Web PKI, you need your own PKI for your very special application. Most people want the Web PKI.
However, my scenario was for situations where you don't want to modify the viewing device.
The advantages of web interfaces is that you get a complex GUI for your device without significant overhead on the device and without any requirements on the viewing machine. You can use an arbitrary PC or phone to access it.
If HTTP were to go, that would change: Either you restrict which machine can view the GUI (by requiring a specific resolver and/or CA) or you add the overhead of maintaining and updating the certificates and domains.
An example would be a (non-cloud) security camera or network printer. Those devices typically have a complex web interface for administration and data access - however, they are typically used within a LAN and there is no technical need why they need to access the internet. Indeed, when misconfigured, they can even be vulnerabilities.
I think this goes deeper. Currently, supporting HTTPS means you have to have some kind of internet connection, back-end infrastructure and other running costs.
Even if you use Let's Encrypt and DNS validation, you will have running costs to keep the domain name registered and you will need some way to periodically transfer new certificates to your devices.
Even if you somehow manage to update the device without a permanent internet connection, if someone wants to access the web interface, they will have to use the domain name - and therefore at least need to be connected to an internet DNS server so the domain resolves.
So if, at some point, browsers would completely drop support for HTTP, this would suddenly force any kind of device with a web interface into an IoT-style lifecycle where the device loses functionality once its vendor is not able to support it anymore - even if the vendor would want people to continue using the device and even if there is no technical reason for it.