I've personally experienced this too: using apt in the presence of a captive portal replaces random bits of `/var/cache/apt` with HTML pages, breaking future updates until you manually find and fix the problem yourself.
The reverse argument also works: using HTTPS may lead you to link and expose, say, OpenSSL where you otherwise would not have needed to. OpenSSL has had dozens of vulnerabilities in the past: https://www.openssl.org/news/vulnerabilities.html
Some of these vulnerabilities have the potential for arbitrary code execution, leaving you worse off than the simpler solution based on the verification of cryptographic signatures that has fewer vulnerabilities by virtue of doing less.
The discussion at https://whydoesaptnotusehttps.com is about the protocol. You can add implementation bug risks to the discussion if you want, but then include the risks from both the approaches being discussed.
You've proposed a reverse argument to an argument that was never made. ctz never said anything about vulnerabilities or implementation issues, they said a captive portal is a problem for apt over HTTP but not HTTPS. This is also true of ISPs that like to insert things into HTTP sessions.
I've personally experienced this too: using apt in the presence of a captive portal replaces random bits of `/var/cache/apt` with HTML pages, breaking future updates until you manually find and fix the problem yourself.