This is what apt already does. The problem is that a malevolent source can see a client downloading package #1, then on seeing a request for package #2 it issues a redirect to a doctored package #1 and because apt stores files based on the remote name and not the requested name, it will overwrite already-downloaded package #1. The validation fails on downloaded package #2 but apt doesn't abort the install process, it simply skips it (and any dependencies) and continues to install the downloaded and previously-validated package #1.
There's plenty of ways to solve this, and none are obvious if you are unaware of this attack vector:
a) use per-package tempdir instead of per-source: no obvious benefit
b) use request package name instead of remote url filename: it would be dangerous for apt to assume that it knows better than a package mirror what the expected filename for a package is (it's strictly defined by Debian policy)
c) immediately delete downloaded package if validation fails: obstructs problem analysis and digital forensics
d) abort install process if a package fails validation: reduces resilience in the face of network errors (e.g. if the mirror is in the process of updating itself)
But yes, it should probably be a Debian installer question: use HTTPS sources or not. Debian is the universal operating system but most users running a desktop or server setup should choose YES. The setups where you really want plain HTTP sources are an edge case and users setting up such systems probably already know about their special requirements, so HTTPS sources should really be presented as the default / "if in doubt" option.
Assuming transport is compromised and you can only trust package signatures IS A GOOD THING. Extra security layer on top of it is nice of course but arguably if it was all https we would've never found this bug and then in case of CA compromise attacker would have plenty of bugs to use to fool apt.
The problem is that they failed ordering of validation; it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used.
There are also edge cases where HTTPS does hurt you, on system without reliable time (and there is quite a few SBCs that don't have RTC) you would just not be able to download the packages at all because all certs are in future.