The other answer is not completely right, hence I‘ll try and fix that.
There are two different types of web interfaces for routers:
The internal and the external web interface.
While the external should be disabled for many reasons, the internal one does not need https to be deployed: as you are accessing the router from your LAN (let‘s just assume, CRACK might be fixed some day and WiFi is considered secure again), a MITM can only operate locally, which is not a big threat in most consumer cases.
Yet, generally it would be desirable to have https on COTS routers. This poses significant problems. While the IP itself would not be a huge problem as the actual IP is only checked when accessing directly via IP (as the IP is taken to be the domain), there is another problem: most SOHO routers either have no DNS zone for the devices or they can be configured.
Even if all routers of one model were to be configured with a not-changeable local domain name like „routerxy.local“, .local is a domain no CA would ever create a certificate for. This is the point the other answers misses. It’s not the storage of the certificate and key that is the deal breaker (it is one as well though, but could be mitigated with an HSM), it is the local domain and how CAs work.
There would be a way to mitigate this problem as well:
Maker x can create routery.x.tld and obtain a certificate for that - and distribute that in the HSM of every box they ship. If this gets leaked (by a vulnerability in the HSM, for example - they are now in the hands of the potential attacker), you are in huge trouble all over again.
Additionally, most CAs might revoke the certificate when they see abuse like that (as the entity the certificate is for is not the one using it)
All in all: there are technical difficulties that hinder usability (we do not want certificate warnings on our COTS router) and there is little benefit from using TLS on a connection that is merely within the LAN.